(X) Hide this
    • Login
    • Join
      • Generate New Image
        By clicking 'Register' you accept the terms of use .

WCF RIA Services Part 9 - Structuring Your Application

(6 votes)
Brian Noyes
>
Brian Noyes
Joined Jun 10, 2010
Articles:   19
Comments:   117
More Articles
30 comments   /   posted on Nov 24, 2010

This article is Part 9 of the series WCF RIA Services.

Introduction

In all the articles up to this point, I have been dumping all the domain service stuff into the single web project that also hosts the Silverlight application. Additionally, I've been putting a lot of functionality into the single Silverlight Application project on the client side. Granted it is only a couple of views so far. But if this app grew to a couple dozen views, I really would not want to be putting all those into a single project. In a real world app, too much code in one place, whether in a single method, a single class, or a single project is a maintenance liability. Additionally, on the server side you might want to start partitioning the code into logical layers, such as breaking out a separate data access layer project from the domain service code, and you might want separate projects for different sets of domain services.

In this article, I'm going to focus on how to break your solution up into multiple projects on both the server and client sides. I'll show how you can break things up into vertical slices that support different use cases in your application or different functional areas. You'll quickly learn how to use WCF RIA Services Class Library projects, as well as how to break things up into multiple XAP files on the client side. Using the Managed Extensibility Framework or Prism 4, you can break up your client application into multiple modules that get developed and built as separate XAP files, and then get downloaded asynchronously when needed by the client application. When you go down this path, unfortunately Visual Studio gets in your way a little bit for setting up your WCF RIA services link with the server project. I'll show you how to easily get past that limitation as well.

You can download the sample code for this article here.

Client-Server Project Relationships


One thing to understand up front is that there are some architectural constraints implied by the use of WCF RIA Services. Because of the way the RIA Services code generation process works, if you want to consume a WCF RIA DomainService from a client project, that client project has to have a link to the server project that contains the domain services you want to consume. That means that a single client project can only point to a single server project. You can have multiple client projects that point to the same server project, and the code generation will happen in each client project. But then if those projects are all used in the same scope, you will have duplicate types defined in the same scope, and will run into problems there. So to keep things clean, you will want to maintain a one-to-one correspondence between a single server project where a set of domain services is defined and a single client project where the client code for those services gets generated. However, the client project can just be a class library that can be reused across multiple modules or client applications. So your architecture will tend to look like this as you start to partition things:

Architecture

Adding a WCF RIA Services Class Library Project

The way to get started breaking things up is to add a new WCF RIA Services Class Library project to your solution. In this case, say I wanted to add some separable functionality to my application, such as the ability to add notes. I would select Add > New Project from Solution Explorer with the solution node selected, and pick the WCF RIA Services Class Library project type.

AddRIALibrary

Once you add this project, you really are adding two projects, the client Silverlight Class Library and a server normal Class Library project. The RIA Services link will already be set between the projects, and it adds them to the solution under a new solution folder.

ClassLibrariesInSolution

You do not really have to use this project type to get this architecture though. You could just add a new Silverlight Class Library to the solution, then add a normal Class Library as well. Then you would just go to the project properties of the Silverlight Class Library and set the WCF RIA Services link drop down to point to the new server class library project. Then you would just have to add the WCF RIA Services references to the client and server projects. This just gets you all that done in one fell swoop. And since the client and server projects are linked, having them in a solution folder is a decent way to group them.

You would then add a new domain service to the TaskManager.Notes.Web project to get started defining your new service functionality and its associated entities. Its code generated client code will end up in the TaskManager.Notes client library. Then you would add a reference from the main client TaskManager Silverlight application to the TaskManager.Notes class library to start using those domain services in the main app. You could add new views and client functionality to that same class library as well. If you wanted to separate out your data access logic into its own class library, you would just add a new class library project and add your Entity Data Model into that project. Then add a reference to that class library from the class library that is going to contain your domain service. Remember to build before adding the new domain service so that it will see your entity framework model and let you pick from its entity types.

The resulting solution tree after adding some views and the data access library is shown below.

SolutionTreeWithDomainService

Using Entities Across Domain Services

In WCF RIA Services version 1, there is a limitation that you cannot have two domain services being used by the same client application that expose the same entity type. This is just a limitation of the way the client side code generation is done, because it will try to generate the same entity type once for each service and you will have duplicate definitions. This is fixed in WCF RIA Services SP1, which is available in beta form at the time of writing this here. But if you stick to the current release version, you will have to factor your vertical slices so that a given entity type is only used in one of the domain service vertical slices.

Breaking Your Client Application into Multiple Modules

As mentioned earlier, using MEF or Prism you can break your client architecture into modules – or separate chunks of functionality that can be downloaded asynchronously at runtime. For this article, I’ll just use MEF directly. I’ll be doing some articles on Prism 4 in the near future as well.

To do this, you need to put your functionality in a project that compiles to a separate XAP file from the main application. That requires you to pick the Silverlight Application template when creating the project, as opposed to a Silverlight Class Library or a WCF RIA Services Class Library project.

If I were going to do something similar to what I showed earlier in the article but wanted that new notes functionality to be downloaded separately as a module the first time it is used, the first step would be to create a new Silverlight Application project in my solution named TaskManager.NotesModule.

AddModuleProject

In the pop up that prompts for creating a server project, uncheck the box for hosting the application.

NoServerProject

After the project is created, delete App.xaml and MainPage.xaml from the new project.

Next you will add the server class library where the domain service will live. Add a new Windows Class Library project and call it TaskManager.NotesModule.Services. You can delete Class1.cs from the new class library project as well. You could then add a domain service to that project, possibly using an entity data model defined in a separate class library as discussed earlier.

If you open the TaskManager.NotesModule Silverlight project settings at this point, the first thing you will need to do is set the startup object to (not set). That is because this project is not intended to be a standalone Silverlight application, but we are just using the Silverlight Application project type because its build output is to produce a XAP file with the contents of the project.

ModuleProjectSettings

The trick comes when you go to set up the RIA Services link.  If you drop down the WCF RIA Services link setting, you will not see the class library that contains your domain service listed as an option. This is really just a bug in the tooling. That drop down really just sets a relative path to the server project in the client project’s csproj file (or vbproj). Since the tool won’t let you set it correctly, you have to open the csproj file and edit it directly.

To do so, right click on the project and select Edit Project File.

EditProjectFile

If that option is not available for you, you can also just open the .csproj in any text editor. The setting you are looking for.is called LinkedServerProject. You need to fill it in with the relative path to the .csproj file of the server project. For example, in my case, the path is:


After adding this and saving the file and closing it, you can then right click on the project in Solution Explorer and select Reload Project. If you then go look at the project settings again, you will see it is now showing the right server project. If you build, you will get the client generated code in your module project from the linked server project.

Using MEF To Dynamically Load the Module

Now all that is left is to load the module dynamically with MEF. I don’t have room for a full lesson on MEF, but what I am going to use here is MEF’s ability to download a separate XAP file asynchronously and then plug in the parts it finds in that XAP to the application dynamically. For a great overview of this capability, I recommend you check out this Silverlight TV Episode with Glenn Block.

The first step is to add the MEF System.ComponentModel.Composition reference to the TaskManager.NotesModule project. You can then mark the parts you want to plug in with appropriate Export attributes. In this case, I am going to plug in a single ChildWindow derived view called NotesView. So I add the following Export to the code behind of that view:

 [Export(typeof(ChildWindow))]
 public partial class NotesView : ChildWindow
 {
 }

Next, I need to add a little code the main app to download the separate XAP file asynchronously when appropriate. First step is to add references to the TaskManager project to System.ComponentModel.Composition.Initialization and System.ComponentModel.Composition. Then I add the following code to the code behind of the main page:

 [Import]
 public ChildWindow PlugInPopup { get; set; }
 bool plugInsInitialized = false;
  
 private void button1_Click(object sender, RoutedEventArgs e)
 {
     if (!plugInsInitialized)
     {
        plugInsInitialized = true;
         var deployment = new DeploymentCatalog("TaskManager.NotesModule.xap");
         deployment.DownloadCompleted += (s, e2) =>
             {
                 CompositionInitializer.SatisfyImports(this);
                 ShowPopup();
             };
         CompositionHost.Initialize(new DeploymentCatalog(), deployment);
         deployment.DownloadAsync();
     }
     else
         ShowPopup();
 }
  
 private void ShowPopup()
 {
     if (PlugInPopup != null)
         PlugInPopup.Show();
 }

The PlugInPopup property will be populated by MEF after the extra XAP is downloaded. Constructing a DeploymentCatalog with a relative path to the XAP file in the host site of this application allows it to download that XAP file asynchronously when told to do so with the DownloadAsync call. You can see that the code subscribes to the completed event for that download, and then calls SatisfyImports to get the container to do dependency injection on this already existing view. At that point the PlugInPopup property gets populated, and is then shown.

The last part to making this work is to add the TaskManager.NotesModule project to the host Web site (it does not need a test page) so that it is in the ClientBin directory and can be downloaded.

The key point here is the need to manually edit the project file to point to the right server project where your domain services live. Just because Visual Studio doesn’t always let you point to any project in your solution (or outside of the solution for that matter), the only requirement is that the LinkedServerProject have a relative path to a compiled project that contains domain services. So a simple edit of the project file gets you want you want to organize your projects how ever you want, as long as you maintain that one-to-one relationship between client and server projects.

Summary

When it comes to organizing and structuring your solution, you can see that you have good flexibility to start breaking up chunks of functionality on the client and server sides into separate libraries and modules however it makes the most sense for your project. You should think in terms of breaking out vertical slices of functionality, composed of a server library project that contains a domain service or several that are related and all their supporting functionality and definitions on the server side. You will link that to a single client project, typically a Silverlight Class Library project or Silverlight Application project if you are trying to be more modular and download modules separately as separate XAPs. Even though you can have a single server project linked from multiple client projects, it will generally cause problems to do so within the same application because of duplicate definitions. So using client side class libraries that just contain the code generated RIA Services code and then referencing that class library from wherever that functionality is needed within the client application gives you flexibility to compose the client side however you want. Also remember that in WCF RIA Services SP1, the constraint on having one domain service “own” a single entity type is lifted.

You can download the sample code for this article here.

About the Author

Brian Noyes is Chief Architect of IDesign, a Microsoft Regional Director, and Connected System MVP. He is a frequent top rated speaker at conferences worldwide including Microsoft TechEd, DevConnections, DevTeach, and others. He is the author of Developing Applications with Windows Workflow Foundation, Smart Client Deployment with ClickOnce, and Data Binding in Windows Forms 2.0. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for code into his current career. You can contact Brian through his blog at http://briannoyes.net/ or on twitter @briannoyes.


Subscribe

Comments

  • -_-

    RE: WCF RIA Services Part 9 - Structuring Your Application


    posted by Shervan on Dec 14, 2010 22:25

    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).

  • -_-

    RE: WCF RIA Services Part 9 - Structuring Your Application


    posted by shervan on Dec 15, 2010 00:21
    sorry, refreshing page made duplicate posts.
  • -_-

    RE: WCF RIA Services Part 9 - Structuring Your Application


    posted by Jeremy on Dec 15, 2010 04:24

    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


    posted by shervan on Dec 15, 2010 08:37
    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


    posted by Brian Noyes on Dec 15, 2010 09:14
    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


    posted by Brian Noyes on Dec 15, 2010 09:15

    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


    posted by Brian Noyes on Dec 15, 2010 09:20
    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


    posted by Per on Dec 17, 2010 20:46

    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


    posted by Brian Noyes on Dec 17, 2010 21:05

    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


    posted by Tad Orman on Feb 10, 2011 20:14
    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


    posted by Brian Noyes on Feb 11, 2011 16:37
    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.
  • markaarnold

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by markaarnold on Aug 07, 2011 18:36
    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
  • brian.noyes

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by brian.noyes on Aug 07, 2011 20:35

    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

  • markaarnold

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by markaarnold on Aug 07, 2011 23:33
    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
  • markaarnold

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by markaarnold on Aug 08, 2011 18:07

    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

  • brian.noyes

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by brian.noyes on Aug 08, 2011 19:41

    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

  • markaarnold

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by markaarnold on Aug 09, 2011 00:59

    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

  • markaarnold

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by markaarnold on Aug 09, 2011 01:25

    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?

     

  • brian.noyes

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by brian.noyes on Aug 10, 2011 21:29

    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.

  • isaac.abraham

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by isaac.abraham on Sep 06, 2011 20:14

    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

  • brian.noyes

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by brian.noyes on Sep 06, 2011 22:20

    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.

  • isaac.abraham

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by isaac.abraham on Sep 07, 2011 13:06

    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

  • isaac.abraham

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by isaac.abraham on Sep 07, 2011 13:38

    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


    posted by on Sep 12, 2011 08:39
    This article is truly relevant to my study at this moment, and I am really happy I discovered your website.
  • brian.noyes

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by brian.noyes on Sep 12, 2011 19:19

    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.

  • atif

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by atif on Feb 18, 2012 21:14
    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.
  • gisbing

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by gisbing on Dec 11, 2012 22:45

    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.

  • brian.noyes

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by brian.noyes on Dec 11, 2012 23:32

    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

  • maxim

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by maxim on Feb 11, 2013 14:28
    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?
  • brian.noyes

    Re: WCF RIA Services Part 9 - Structuring Your Application


    posted by brian.noyes on Feb 11, 2013 15:16

    @briannoyes

Add Comment

Login to comment:
  *      *       

From this series