Is it possible to have communication between WPF client app written in .net framework and microservices written in .net core?
Yes.
Microservices are services.
They would usually be http and could be REST. Web API would be the commonly used option with core.
The fact the service is written in .net core would make no difference because it's just HTTP.
You could make the call from wpf using httpclient.
https://learn.microsoft.com/en-us/previous-versions/visualstudio/hh193681(v=vs.118)
Example code
https://learn.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client
Related
I am a naive developer and I am building up my concepts, I was asked to create a sample application in wcf, and so I am asking a bit subjective question here.
I want to know the diffrence and functionality of the above two, in which terms we prefer one over other?
WCF = Windows COMMUNICATION Foundation
WPF = Windows PRESENTATION Foundation.
WCF deals with communication (in simple terms - sending and receiving data as well as formatting and serialization involved), WPF deals with presentation (UI)
The quick answer is: Windows Presentation Foundation (WPF) is basically a way of displaying user interface. (see this)
Windows Communication Foundation (WCF) is a framework for creating service oriented applications. (see this)
As for which one you should use, it depends on your requirement. Usually an application written in WPF, ASP.NET..etc called the WCF service to do some processing at the server-side and the service returns the result to the application that called it.
Windows Presentation Foundation (WPF)
Next-Generation User Experiences. The Windows Presentation Foundation, WPF, provides a unified framework for building applications and high-fidelity experiences in Windows Vista that blend application UI, documents, and media content. WPF offers developers 2D and 3D graphics support, hardware-accelerated effects, scalability to different form factors, interactive data visualization, and superior content readability.
Windows Communication Foundation (WCF)
Windows Communication Foundation (WCF) is Microsoft’s unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments.
WPF is your FrontEnd (presentation: .htm, .xaml & .css, ..)
WCF is your BackEnd app (services that involve server connections to acquire data for you to deliver to the FrontEnd to present). You can write WCF for RESTful model.
WebAPI is for building services of RESTful model for 4.+ frameworks.
Basically, if you are developing a client- server application. You may use WCF -> in order to make connection between client and server, WPF -> as client side to present the data.
WCF = Windows Communication Foundation is used to build service-oriented applications.
WPF = Windows Presentation Foundation is used to write platform-independent applications.
Windows communication Fundation(WCF) is used for connecting different applications and passing the data's between them using endpoints.
Windows Presentation Foundation is used for designing rich internet applications in the format of xaml.
We are building a new system from scratch and have decided on SL4, WCF RIA Services and EF4.
So I see the WCF RIA services as the business logic of the SL client, but can it be used as a general business logic layer, that can be used by other parts of the application. As an example the WCF RIA service will have security implemented (such as who is allowed to do what with which objects). But this security implementation should also be by other parts of the system and not only by the SL client.
To avoid having this logic duplicated my idea is to use the WCF RIA service as a general business layer meaning that if other parts of the system needs access to the datalayer they would need to go through this layer.
But is this an ok usage of WCF RIA?
Thanks
What you're describing is the standard WCF RIA pattern and is how the WCF RIA team designed the system to work.
WCF RIA will allow you to get end-to-end access to your EF4 entities and hide your business logic behind the RIA service interface. You can apply authentication and authorization attributes to your entities in the service definition (domain service class) at either the class level (all methods in the service contract) or the method level for more granular control.
The only major flaw I see in your plan is "other parts of the system needs access to the datalayer they would need to go through this layer". WCF RIA at this stage only plays well with Silverlight (and maybe ASP.NET MVC? I am not sure). Microsoft eventually intends to extend RIA Services to be consumed by any kind of .NET application but at this stage it's really a Silverlight-only thing. This means that you'll miss out on a lot of the WCF RIA goodies with your other non-Silverlight applications. However I believe you can still expose the WCF RIA service as an ordinary WCF service, including the authentication/authorization layer. You'll just miss out on the automatic proxies, code generation, etc.
There are still several ways of using this service layer from outside of Silverlight however. You can expose your EF4 entities with an OData endpoint or SOAP/REST service. For more details on this, check out this article.
In the big RIA project we usually have so many modules ( Business modules, licensing, authorization, Audit modules etc.) and obviously there are some modules that need to be accessed across other modules and also some across the SL client. So I believe your concern is a typical architecture side on how you make this properly distribute in a big application. As in any .NET project, you can modularize it in to different library projects. That means you can appropriately make some as RIA Service Class Library project or else typical reusable .net libraries ( for example, Logging library)
I'm using hessian protocol for communication betwee server (java) and various client applications. Now I started to develop Windows Phone 7 client. I downloaded hessian C# implementation but it does not compile for windows phone 7/silverlight.
Does anyone managed to make it work on WP7/Silverlight? It's looks like there is many thing to be done/changed to make it work, which I'd like to avoid if it has been done by someone already.
Thanks.
What is it that does not compile? I'm guessing that the implementation is probably using sockets. Please keep in mind that Silverlight (and thus, wp7) limits the kinds of network connections you can open ... preferring asynchronous web requests (via the WebRequest class) or WCF services.
Chances are the code you downloaded is having problems with the compact framework version of the network classes available on the phone/silverlight. See this msdn article for more information about the socket support:
http://msdn.microsoft.com/en-us/library/cc296248%28VS.95%29.aspx
If you want to communicate directly between the phone and a server running the hessian protocol the easiest way will probably be to proxy communication via a wcf service running on an asp.net server.
So answer is you have to rewrite hessian C# implementation as Silverlight 4 doesn't have lot of stuff from .net mobile framework, mainly Proxy class.
I've asked several questions on Silverlight the last day or two (I have no experience with it), and I've had some high-level questions answered. I have another high-level question. How is N-Tier development done with Silverlight? What I am considering is a browser based UI and then a c# back-end containing all the business logic and database code. How would a Silverlight client application communicate with such a back-end sitting on another server? Would it be done via Web service calls, WCF or something else? What is standard practice?
Thanks!
For the projects I've worked on. Typical practice is Silverlight providing a client and then communicating back to the back-end via WCF services.
The business logic is then spread/duplicated across the client and the backend.
You'll want to be looking at the WCF RIA Services for this. In combination with Entity Framework this will approach the sort of thing you need.
The Entity Framework creates model that you can extend and include some business logic.
The Domain Services then allow you to expose access to the model and any other range of operations you need via WCF.
The tooling that RIA Services adds to the Visual Studio will dynamically create in the Silverlight application the client side of this Domain service. There is even a provision for you create C# source that is shared by both by both Silverlight and the server code.
If its Silverlight 3 RIA is a better choice to work with. AnthonyWJones has pointed it right, There is a provision to have a shared Source between Client and Server usually Entities code should be shared in both Client and Server to get full advantage of RIA validation and other stuff.
I'm rewriting an LOB application whose architecture is like this:
Silverlight && Windows Mobile -> WCF
-> Entity Framework -> Database.
The mobile app was supposed to be able to do certain things as the silverlight app. What benefits would I get from using RIA Services here? Whats the advantage and disadvantage of RIA Services over WCF?
.NET RIA Services was created for Silverlight that runs in the browser. Silverlight is running a special version of the the .NET framework and in an N-tier application Silverlight is unable to share assemblies with the server side. By employing some clever code generation .NET RIA Services makes this gap almost invisible to the developer. Classes similar to the domain classes are code generated on the client side, and ways to move objects back and forth between client and server are also made available.
You will probably be able to call into a .NET RIA Service from Windows Mobile, but I don't think it will particular easy and currently you may in fact have to reverse engineer what's sent on the wire (JSON is used). WCF on the other has a much more broad scope, but doesn't support Silverlight development in the same way that .NET RIA Services does.
If you are writing a Silverlight only N-tier application .NET RIA Services are very powerful. If however Silverlight is only one of several clients WCF is probably a better choice.
Please note the .NET RIA Services hasn't been released yet, but a preview is available for download.
WCF RIA Services introduces several solutions for challenges you run into when using WCF from Silverlight. For instance, asynchronous loading of queries using the EntityQuery<T> is much easier than the Begin..End solution offered by WCF. Also, RIA provides integrated change tracking from your client that allow to submit or reject multiple changes as one change set. RIA will bundle all these changes into one request, but from your Domain Service it behaves as it were individual calls. As a long time WCF developer I can tell you that that is a breeze.
Ria services are created just to be used with Silverlight. They are substantially a standard "package" ready to be used by Silverlight. The advantage is that you have a lot of services without need to write code i.e.:
Support for data annotations
Support for membership provider and login
Support for transferring to silverlight server side generated exceptions. There is a difficulty in silverlight that make difficultthe normal error transfer of exception through FaultContract. The point is that the browser is not able to handle all error codes. Ria services solve this with a trick
All things done by Ria can be done with WCF and with other available software and in particular with Wcf data services. For instance for data annotations I found this library that do a better job than Ria services, support for membership just require activating the already existing membership endpoint of a WCF service, and finally the exception problem is easily resolved by writing a WCF behaviour. Code is available here:http://www.silverlightshow.net/Storage/10Tips.zip
The point is that with Ria Service you have all this in a mouse click!. On the other side Ria Services are really difficult to customize...so if you don't like the standard solution they offer you simply can't use them
RIA Services is built on top of WCF. With the PDC release, this will be much more evident. RIA Services simplifies the client-side programming model so that it matches very closely with your server-side DomainService and entities.
Regardless to the answer:
RIA Services is built on top of WCF.
With the PDC release, this will be
much more evident. RIA Services
simplifies the client-side programming
model so that it matches very closely
with your server-side DomainService
and entities.
For me (and I guess that for the topic author) it is not clear what RIA services provide also besides access to the DomainService (which is same thing provided by WCF)?
Thanks.
Until there is a formal release of WCF RIA Services, I don't think there is a definitive answer to this question. As of the current Beta (for VS 2008, SL 3), RIA Services does not hide the asynchronous nature of service calls; you still need to provide a callback method. Also, RIA Services does not currently support user-defined classes (or collections of user-defined classes) as either parameters or return values on RIA service calls. I'm also running into trouble providing non-editable entity classes through RIA Services. (The error says the entity collection isn't editable. Yeah, that is actually what I want....)
At this point, I need to fall back and take another look at making plain old WCF work. That's not so simple, given the size of the application we're developing, but it seems to be the workable solution until MS fixes some of the current problems with RIA Services.
.NET RIA Services had been named as WCF RIA Services in PDC which was held in November 2009. Since it is built on top of WCF, hence the name WCF RIA Services.
You'll need to use WCF RIA Services for building N tier application involving database(or any information that needs to be carried along the tiers).