(Using Visual Studio 2008, and Silverlight 3)
-I've really looked around for this one, and now I'm just confused by all the solutions that simply won't work for me.
I'm trying to call a WCF service from a Silverlight client, which is no problem, but I can't get the service to handle sessions (I want to remember a few things about the callee between calls)
I've gathered that basicHttpBinding is no good for sessions, and I haven't managed to make wsHttpBinding work... what's the matter? I would have thought this was a pretty basic thing people would want in their WCF services, or am I just completely muddle-headed not to see how it can be done?
okay, seems like "Silverlight-enabled WCF Services" (WCF service with
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
and basicHttpBinding instead of wsHttpBinding) can do sessions with Silverlight:
http://www.dotnetspider.com/Silverlight-Tutorial-317.aspx
Cheers, Alex
Related
I looking for a way to query the CRM 2011 database with from a Silverlight client. Something like LINQ-to-CRM but for 2011 and Silverlight. I googled a lot but to no avail.
I know it is possible with the "normal" SDK, but with Silverlight?
Is there a way to do this?
Best,
Rocko
CRM 2011 exposes its own WCF data service which it calls the ODATA service. You can query this from client code (e.g. Javascript or SilverLight), and there should be examples of this in the SDK.
Download the SDK from here, and look in this folder: sdk\samplecode\cs\silverlight\crmodatasilverlight
I know this isn't 'LINQ to CRM' as such but it's perfectly adequate. Otherwise, you could look into Dynamic Entities as a method of returning data, as this would let you send LINQ queries; see here.
Your best bet would be to create a WCF service that serves up the data (could even be an ado.net service) and then make a reference to the WCF service from your Silverlight application.
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.
At work, I want to create a WCF Windows Service that runs on a network server. Then I want to create a WPF application that can be installed on various machines on the network. This WPF application needs to be able to communicate with the WCF Windows Service on the network server.
Is this feasible? Is there a better way to accomplish what I want to do? Does anyone know of any resources that show examples of this? I found some tutorials how to setup a WCF service within a Windows service, but I am unsure how to communicate with it over a network.
Thanks for any advice!
Yes, a WPF application can host a WCF client just as well as (and in the same way as) any other .NET application. You may run into security limitations if your application is packaged as an XBAP for browser delivery, but otherwise it should all just work.
Similarly, a Windows service can host a WCF service. For an example see "How to Host a WCF Service in a Managed Windows Service" at http://msdn.microsoft.com/en-us/library/ms733069.aspx.
You can then communicate with it over the network by creating a client proxy -- the easiest way to do this is to use the Visual Studio Add Service Reference command.
I don't understand your question. You say you saw examples of WCF servers and clients, but you are unsure how to communicate with it over a network. But all of the examples you saw were about the clients and servers communicating over the network!
What's the difference between what you saw in the samples, and what you want to accomplish yourself?
Last try to get an answer on this.
I have a simple ASP.NET app which uses Hibernate for data access.
GUI can call methods on Customer object like "CalculateTotalSumOfOrders()".
Lazy loading (even though it's not optimal) will work for me, and when Orders and OrderLines collections are referenced in the domain objects, they will get automatically fetched from the database.
Now let's assume I am rewriting the same very app to Silverlight because it looks better than ASP.NET.
I am NO longer able to do lazy loading or data access, because Silverlight client runs in the browser.
How can I solve this without thinking too much about what kind of service to use to get data into the Silverlight client?
Your best bet for supporting all of those platforms is to use a web service. There are many different flavors that you can choose from, .NET 2.0 Web Services (ASMX), WCF, REST, if you are using Silverlight, you may want to consider using WCF + LINQ to SQL which is demonstrated here. That combination can also be used in ASP.NET (if running on .NET 3.5) and Windows Desktop Apps (again .NET 3.5).
Also an open source project called InterLinq might be interesting to you, basically it allows you to build LINQ to SQL queries on the client side, and then transmit them through WCF to a server that executes the query and returns the result. That can be found here. I have experimented with it in the past and it works quite well.
One option that would support Silverlight and Windows clients would be the new ADO.NET Data Services in .NET 3.5 SP1. These are a set of services that expose your database schema through a WCF interface. You can then retrieve the data from Silverlight or a Windows Client using a WCF client.
As #McWafflestix has said, you won't be able to do lazy loading any more, but in my opinion that's a good thing because retrieving data is now a much more "expensive" operation.
You're trying to take a server-side app that interacts with your database and does lazy loading, and convert it into a client-side app without a lot of work? Sorry, it's just not going to work. What you need is a major rearchitecting of your application.
Sorry...
*
"That's okay because I'm quite early
there. How would you rearchitect it to
support both ASP.NET, silverlight and
windows clients with minimal
overhead?"
*
I know I am answering this question way past the expiry, anyhow here goes. I would suggest you use the MVP design pattern; this would help you build multiple "Views" to work with your Model. In order to ensure that you support Windows clients, you would have to expose your Business Layer using a services layer (read WCF).
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).