locked
WCF RIA Service and Presentation Model... RRS feed

  • Question

  • We are developing Silverlight 4 based LOB application. The application uses EF and WCF RIA services. Is it a bad practice to simply return the entities "as is" without any translation? Our fear is that it tightly couples the data entities with presentation layer. I understand EF supports POCO, but not sure exposing the auto generated POCO solves the "tight coupling" problem. I'm looking from the community on the best practice and pattern to use RIA services in a right way. Sincerely appreciate your advice.

    Tuesday, July 19, 2011 2:18 PM

Answers

  • I have an answer for you, but first a few notes:

    1. The client side entities are not the same objects as the server side entities.
    2. If you want you can control the generation of the client side entities by providing your own T4 template.
    3. RIA Services does have Presenation Model support. Documentation at http://msdn.microsoft.com/en-us/library/ee707347(v=VS.91).aspx
    4. RIA Services should be thought of as part of the Business Logic Layer (BLL) of your application, not part of the Data Access Layer (DAL). It is just an n-tier enabled version of a BLL.

    OK, with those out of the way, I will tell you my current thinking on this. This is new thinking, I mentioned some of this to a few people but I really haven't said anything publically about this. Here is what I am thinking:

    1. Create your EDMX file
    2. Setup the EDMX file to generate a DbContext instead of ObjectContext (http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4-1-model-amp-database-first-walkthrough.aspx)
    3. Create a DbDomainService (http://jeffhandley.com/archive/2011/06/30/RIAServicesCodeFirst.aspx and http://varunpuranik.wordpress.com/2011/06/29/wcf-ria-services-support-for-ef-4-1-and-ef-code-first/)
    4. Once you are pretty far along in development and your database structure has been proven and stableized, drop the EDMX file from the project, remove the "this code is generated" warning from the top of the previously generated DbContext classes, and take ownership of your server side entities.

    I think this scenario is an eat your cake and keep it too scenario. You get the benefit in the beginning of easily keeping your objects in sync with the database and then later you get to decouple the objects without having to make any code changes.

    As a side note, on the client side of your application, it is important to decouple your ViewModel from the DomainContext. To see how to do that, check the WCF RIA Services and MVVM link in my signature. I also have a set of snippets on my blog that will help make it easier to create DbDomainService classes and there is a scaffolding system currently being worked on as well.

     

     

    Tuesday, July 19, 2011 3:03 PM

All replies

  • I have an answer for you, but first a few notes:

    1. The client side entities are not the same objects as the server side entities.
    2. If you want you can control the generation of the client side entities by providing your own T4 template.
    3. RIA Services does have Presenation Model support. Documentation at http://msdn.microsoft.com/en-us/library/ee707347(v=VS.91).aspx
    4. RIA Services should be thought of as part of the Business Logic Layer (BLL) of your application, not part of the Data Access Layer (DAL). It is just an n-tier enabled version of a BLL.

    OK, with those out of the way, I will tell you my current thinking on this. This is new thinking, I mentioned some of this to a few people but I really haven't said anything publically about this. Here is what I am thinking:

    1. Create your EDMX file
    2. Setup the EDMX file to generate a DbContext instead of ObjectContext (http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4-1-model-amp-database-first-walkthrough.aspx)
    3. Create a DbDomainService (http://jeffhandley.com/archive/2011/06/30/RIAServicesCodeFirst.aspx and http://varunpuranik.wordpress.com/2011/06/29/wcf-ria-services-support-for-ef-4-1-and-ef-code-first/)
    4. Once you are pretty far along in development and your database structure has been proven and stableized, drop the EDMX file from the project, remove the "this code is generated" warning from the top of the previously generated DbContext classes, and take ownership of your server side entities.

    I think this scenario is an eat your cake and keep it too scenario. You get the benefit in the beginning of easily keeping your objects in sync with the database and then later you get to decouple the objects without having to make any code changes.

    As a side note, on the client side of your application, it is important to decouple your ViewModel from the DomainContext. To see how to do that, check the WCF RIA Services and MVVM link in my signature. I also have a set of snippets on my blog that will help make it easier to create DbDomainService classes and there is a scaffolding system currently being worked on as well.

     

     

    Tuesday, July 19, 2011 3:03 PM
  • Thank you very much!

    Tuesday, July 19, 2011 3:18 PM