SilverlightShow: WCF RIA Services Part 9 - Structuring Your Application Comments

Re: WCF RIA Services Part 9 - Structuring Your Application

akirti — Thu, 10 Jul 2014 00:08:54 GMT

http://stackoverflow.com/questions/24663776/multiple-ria-service-library-issue-with-prism-4-1-and-silverlight-5

Please help

Re: WCF RIA Services Part 9 - Structuring Your Application

brian.noyes — Mon, 11 Feb 2013 15:16:43 GMT

@briannoyes

Re: WCF RIA Services Part 9 - Structuring Your Application

maxim — Mon, 11 Feb 2013 14:28:12 GMT

Hello Brian, that was a very interesting and educational article/tutorial. Thanks a lot for sharing, have learned a lot. Do you by any chance have twitter or facebook?

Re: WCF RIA Services Part 9 - Structuring Your Application

brian.noyes — Tue, 11 Dec 2012 23:32:31 GMT

The only config that ever matters at runtime is the one in your web.config for a web app or the app.config for an exe (i.e. WCF self-hosting). The app.configs you see in libraries are there for design time support - for example Entity Framework will generate an app.config connection string in a library project if you add a DB first model there, but that one is not used at runtime. You need to copy it to your web.config.

Code generation never touches your metadata files after the initial code gen of the DomainService. So you will have to keep those in sync with model/schema changes manually.

HTH, Brian

Re: WCF RIA Services Part 9 - Structuring Your Application

gisbing — Tue, 11 Dec 2012 22:45:56 GMT

Hi Brian,

Thanks for the great posts.I have 2 modules (using Prism Unity) and each has it's own domain services. I followed your post but the App.Config still in the module service project. In your sample code, there is a same connection string in web.config in host web project. Which one is used? What is the appropriate location for the connection string, considering I'll need to add authentication later that controls different user can only access different module?

Another question is if I modify metadata class and use shared code, if my database schema changes I need to update my domain service. Are the modification in metatdata class and shared code going be retained?

Thanks.

Re: WCF RIA Services Part 9 - Structuring Your Application

atif — Sat, 18 Feb 2012 21:14:28 GMT

Great topic i am using this approach in my projects and this structure working very well although i face some challanges when viewmodel share between 2 modules.

Re: WCF RIA Services Part 9 - Structuring Your Application

brian.noyes — Mon, 12 Sep 2011 19:19:59 GMT

Issac,

Sorry, didn't see your question until now. I have not tried that, but custom T4 templates are part of SP1, so yes, you might be able to suppress generation of the entities with custom templates, but not sure how you could apply those on a project by project basis.

Re: WCF RIA Services Part 9 - Structuring Your Application

Mon, 12 Sep 2011 08:39:55 GMT

This article is truly relevant to my study at this moment, and I am really happy I discovered your website.

Re: WCF RIA Services Part 9 - Structuring Your Application

isaac.abraham — Wed, 07 Sep 2011 13:38:18 GMT

Brian

Just a thought - do you think it would be possible to use the T4 template process to prevent an entity being code-gened on the client proxy? Even if it was hard-coded into our T4 template code, this would be preferable than the alternative, which is to merge the domain service assemblies into one uber assembly.

Cheers

Isaac

Re: WCF RIA Services Part 9 - Structuring Your Application

isaac.abraham — Wed, 07 Sep 2011 13:06:38 GMT

Hiya Brian

Yes, I came to pretty much the same conclusion - there's no way at build time that they could determine it because, as you say, each client proxy would need to know about the other one. I've got around it so far because I'm not actually referencing the type in code - I only reference the properties for binding in XAML - but at some point I might need to refactor the projects as you say.

Thanks for the sanity check though - everywhere I looked I saw "SP1 fixes this"! :-)

Isaac

Re: WCF RIA Services Part 9 - Structuring Your Application

brian.noyes — Tue, 06 Sep 2011 22:20:47 GMT

Hi Isaac,

One of the features of SP1 was to fix the fact that prior to that they would always generate duplicate entity types if an entity was used by more than one domain service. The only hitch is that the fix only applies if the domain services are part of the same server project and therefore same client library. This forces you to keep domain services that use shared entities grouped together in the same project, which might make some sense anyway since there is some inherent coupling there if they are using the same types.

I've asked myself why they didn't take the fix further and make it so it doesn't create duplicate types even if they are separated across projects, and the only answer I could come up with for myself was "how in the world could they solve that"? The client side code generation only knows about it's linked server project and the types defined there. If you have two server projects and two linked client projects, there would have to be an unambiguous way to define which types to exclude. I could imagine a client config entry or something that would allow you do define excluded types, but then for that project to compile you would need a reference to the project into which the types were going to be generated, but they don't exist until build time, so then you have to express build order dependencies and etc. Just gets too ugly.

The solution is just to factor your services differently to keep those that use shared types in a common service assembly and problem solved.

They do call RIA Services a "Prescriptive Architecture" for a reason.

Re: WCF RIA Services Part 9 - Structuring Your Application

isaac.abraham — Tue, 06 Sep 2011 20:14:00 GMT

Brian

Thanks for the post. Just a quick question - I am having big issues with RIA Service SP1 with duplicate entity types being generated. I have two domain service projects which expose a few services; both have associated client-side proxy projects. Both of these domain service projects reference a third assembly which contains a type - lets call it Employee - that both services in both domain service projects use in their method signatures.

This Employee type gets generated in both client proxy projects, which of course mucks up the build of the client silverlight solution.

Have you seen this before?

Thanks

Isaac

Re: WCF RIA Services Part 9 - Structuring Your Application

brian.noyes — Wed, 10 Aug 2011 21:29:05 GMT

WAS and IIS get used interchangably by some. In terms of deployment they have the same deployment model - put your service DLLs in the \bin folder and put an .svc file in the site. It is really only configuration of the machine (through IIS Manager or command line tools) and the transport protocols you can use that differentiate WAS and IIS - IIS being HTTP only, and WAS capable of any protocol.

Since RIA Services is using HTTP as a REST-based service, IIS is where you will be unless you go out of your way to be self hosted. So hosting with was does not really make sense.

Re: WCF RIA Services Part 9 - Structuring Your Application

markaarnold — Tue, 09 Aug 2011 01:25:57 GMT

Sorry about the double posts. I hit refresh to see updates and end up re-submitting.

That definitely answers it. Feeding a different URI in the constructor will do the trick! As to hosting the remote domainservice, is it possible to host it using WAS as you would a native WCF service? Or do I have to publish the server project to IIS on the remote server?

Re: WCF RIA Services Part 9 - Structuring Your Application

markaarnold — Tue, 09 Aug 2011 00:59:51 GMT

I've been thinking about this more and my fundamental question is this:

Is it possible to develop a silverlight app that can consume ria domainservices hosted on a geographically remote machine? Assume I have control of all machines involved and I can develop all parts of the app on my local desktop so I can add necessary ria services links for codegen during development.

Mark

Re: WCF RIA Services Part 9 - Structuring Your Application

brian.noyes — Mon, 08 Aug 2011 19:41:49 GMT

Hi Mark,

It is absolutely possible to have the RIA Services remote from the hosting server for the Silverlight app. As a productivity boost, RIA Services assumes your services are hosted on the same site your Silverlight app was loaded from. However, the DomainContext constructor has an overload that takes a Uri so that you can point to a different location where you choose to host them.

Does that answer it?

Brian

Re: WCF RIA Services Part 9 - Structuring Your Application

markaarnold — Mon, 08 Aug 2011 18:07:19 GMT

I've been thinking about this more and my fundamental question is this:

Mark

Re: WCF RIA Services Part 9 - Structuring Your Application

markaarnold — Sun, 07 Aug 2011 23:33:41 GMT

Thanks Brian. So is it sensible to think the RIA services link is only needed at design time? In that case could you add an SL class lib to the solution and develop with code gen goodness, then compile the class library and host it on a remote server for the main xap to call at runtime (presumably this would take some binding tweaks at runtime to point to the class lib, and hosting would require IIS). Or maybe develop the class lib in a different solution to compile separately? Mark

Re: WCF RIA Services Part 9 - Structuring Your Application

brian.noyes — Sun, 07 Aug 2011 20:35:04 GMT

Don't let the "magic" of Visual Studio get in the way of understanding what is really happening under the covers. Bottom line is that after you hit compile, you have a Silverlight XAP with some class libraries in it on the client and a set of class libraries on the server. You could develop every project in a separate solution and still bring them together at runtime if you get the right pieces in the right place.

The main thing is that you have to have a compiled server project on disk that contains the RIA domain services you want to consume from a Silverlight client application or class library. Then you need a Silverlight Application or Class Library project that you can set up the RIA link to point to that server project. You can actually open the XML of the csproj or vbproj file and manually add the relative path to the server project even if it is not part of the same solution.

But you will need that server project link in the client project to get the client side RIA code generation that is most of the point of using RIA services in the first place.

Hope that helps.

Brian

Re: WCF RIA Services Part 9 - Structuring Your Application

markaarnold — Sun, 07 Aug 2011 18:36:58 GMT

Brian Is there anyway to create an SL class lib in a separate solution then deploy to a remote server from the parent web without breaking the ria links? I'm trying to have a single client make ria services calls back to the parent web AND to differed local servers without resorting to native WCF services. I'm thinking of something like a solution with SL class lib and related DAL, perhaps hosted in it's on service on the remote servers but I'm not sure that's sensible. Thanks Mark

RE: WCF RIA Services Part 9 - Structuring Your Application

Brian Noyes — Fri, 11 Feb 2011 16:37:43 GMT

Tad: I'd strongly recommend looking at Prism. Two of its primary features is modularity and UI composition, which are very similar to what I described here in pure MEF terms. And it works the same for both WPF and Silverlight apps, and can use either MEF or Unity as the container under the covers.

RE: WCF RIA Services Part 9 - Structuring Your Application

Tad Orman — Thu, 10 Feb 2011 20:14:55 GMT

Hey Brian! We are building a WPF application and would like to partition it much like what can be done with XAPs and the MEF DeploymentCatalog in Silverlight. .... but there appears to be no kind of equivalent for WPF. Any guidance on this concern? Thanks! Tad

RE: WCF RIA Services Part 9 - Structuring Your Application

Brian Noyes — Fri, 17 Dec 2010 21:05:23 GMT

Hi Per,

I've always wished that Entity Framework had the capability out of the box to put the entity definitions in a different library than the model and the object context class. It seems weird that they added the capability to do that with data sets in 3.5 (put the typed data set definition in a separate project from the table adapters) but they have not done that yet for EF. Since the buddy class is a partial class, it has to be where the entity classes are, which means where the model is. You can definitely put those in a different library from the domain services though. Just because RIA Services code gens them in the same library doesn't mean you are stuck with that. The server code gen is a one time thing, you can always move the metadata class to another library and reference it from the domain service library.

RE: WCF RIA Services Part 9 - Structuring Your Application

Per — Fri, 17 Dec 2010 20:46:40 GMT

Thanks for posting this Brian!

I would like your opinion on how to deal with MetaData in this kind of project structure. Most examples we see out there makes use of some form of 'buddy' classes that are compiled together with the 'entity' classes', which cannot really be done in a clean way when you split the .edmx into a different project from where the DomainService reside...

RE: WCF RIA Services Part 9 - Structuring Your Application

Brian Noyes — Wed, 15 Dec 2010 09:20:03 GMT

Shervan, You are absolutely correct. I meant to say that in the article, but it appears I failed to. After adding the RIA Services Class Library project, the next steps would be to add a reference from the main Silverlight application to the client side class library, and a reference from the hosting web project to the server side class library so that the server side one deploys to the \bin directory of the hosting web site.

RE: WCF RIA Services Part 9 - Structuring Your Application

Brian Noyes — Wed, 15 Dec 2010 09:15:54 GMT

Jeremy, there is a dependency on the Silverlight Toolkit, which is where the Silverlight Unit Test Framework lives:

http://silverlight.codeplex.com/

RE: WCF RIA Services Part 9 - Structuring Your Application

Brian Noyes — Wed, 15 Dec 2010 09:14:11 GMT

Shervan, You can add a reference from the main application to the class libraries in the first approach, and can also add a reference from the main application to the modules in the second approach and access the domain services from main application or modules/class library in either. The module based approach just gives you the opportunity to download the modules separately from the main application, which can help a lot with startup time and also if you have functionality that is only sometimes used, it saves those users who never use that functionality from ever needing to download and consume the memory for loading it.

RE: WCF RIA Services Part 9 - Structuring Your Application

shervan — Wed, 15 Dec 2010 08:37:56 GMT

for the first approach (WCF RIA Libraries) according to http://msdn.microsoft.com/en-us/library/ee707351(v=VS.91).aspx not only silverlight project should reference the client library, but also main website should reference library web project (TaskManager.Notes.Web). As I tested bith were required.

RE: WCF RIA Services Part 9 - Structuring Your Application

Jeremy — Wed, 15 Dec 2010 04:24:40 GMT

Hello Brian:

Are there any special instructions for loading your solution? when I open it, the Tests project fails to load. It appears to be unable to load Microsoft.Silverlight.Toolkit.Build.Targets. Maybe I'm missing a prereq? Here's what I have installed

Visual Studio 2010 Ultimate edition

Silverlight 4 developers sdk

RIA Services SP1 Beta

Ria Services Toolkit (December 2010 drop)

I did find the missing assembly on my disk. For some reason, VS was looking for it in my project directory, and not in the path specified in the csproj file.

RE: WCF RIA Services Part 9 - Structuring Your Application

shervan — Wed, 15 Dec 2010 00:21:12 GMT

sorry, refreshing page made duplicate posts.

RE: WCF RIA Services Part 9 - Structuring Your Application

Shervan — Tue, 14 Dec 2010 22:25:16 GMT

Hello Brian,

I am new to all of these. So; would this be correct:

In the first approach (Adding a WCF RIA Services Class Library Project) you can access the domain service directly in your main application as you normally do.

In the second approach (Breaking Your Client Application into Multiple Modules) there will be no domain servie accessible to the main silverlight project. You have to make a user-control and only that is available to the main project. MEF can give you only access to user-controls or user defined clasess, but generated classes (ex. domain servies) are more likely to be inaccessible (in this case sealed class).