locked
LightSwitch Best Practice to structure the RIA Service Project RRS feed

  • Question

  • I have a LightSwitch Web Application with a WCF RIA Service Project. The DomainService class within this project is now very large (has many classes inclusive private methods).

    Please, how can I reorganize this within the RIA Service Project according with the best practice?

    Should I extract each entity class in a new folder within this project?

    Many, many thanks.

    Tuesday, May 20, 2014 11:32 AM

Answers

  • If the Main class inherits from the Domainservice class and all the other classes then inherit from the Main class then all those other classes will definitely also show up as data sources when attaching the data source in LS.

    Using the concept of partial classes like I described above overcomes that issue.


    Regards, Xander. My Blog

    • Proposed as answer by Simon Jones [MSDL] Wednesday, May 21, 2014 4:28 PM
    • Marked as answer by Angie Xu Tuesday, June 3, 2014 8:09 AM
    Wednesday, May 21, 2014 11:01 AM
  • There is no Customers.cs in the example above, only a Ds.Customers.cs and it is a partial domain service class and not a nested class. There are no nested classes.

    The reason for using partial classes in my pattern is to allow you to split the domain service class into multiple files to make it more maintainable.

    So you would have the following for the domain service partial classes:

    Ds.cs
    public partial class OrderManagementDomainService : DomainService
    {
    // initialization, count, etc
    }

    Ds.Customers.cs
    public partial class OrderManagementDomainService
    {
    // public query/update/insert/delete methods for CustomerModel
    }

    Ds.Orders.cs
    public partial class OrderManagementDomainService
    {
    // public query/update/insert/delete methods for OrderModel
    }

    Ds.Invoice.cs
    public partial class OrderManagementDomainService
    {
    // public query/update/insert/delete methods for InvoiceModel
    }

    And then for the model entities:

    CustomerModel.cs
    public class CustomerModel
    {
    // public properties for Customer model
    }

    OrderModel.cs
    public class CustomerModel
    {
    // public properties for Customer model
    }

    InvoiceModel.cs
    public class InvoiceModel
    {
    // public properties for Invoice model
    }



    Regards, Xander. My Blog

    • Edited by novascape Tuesday, May 27, 2014 9:27 PM
    • Marked as answer by Angie Xu Tuesday, June 3, 2014 2:30 AM
    Tuesday, May 27, 2014 9:25 PM

All replies

  • It is usually best practice to keep each class in a separate file. How you group those files into folders is up to you. I usually do it by gathering related classes together into functional groups. I also keep generic helper functions in a separate folder.

    Simon Jones
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.

    Tuesday, May 20, 2014 1:14 PM
  • When I structure my classes such that the base domain service is in one file and the entity classes that inherit from it are in separate files, each class, including the base class that has no entities, is showing up as its own datasource.  Is that correct?  I want to be able to separate the files for organization but have the domain service and all classes show up as one datasource.  Am I doing something wrong here?
    Tuesday, May 20, 2014 4:05 PM
  • Does only your main class Inherit DomainService?


    Simon Jones
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.

    Tuesday, May 20, 2014 4:23 PM
  • I don't know about universal best practises, but this is what my own best practises are and what has worked quite well for me thus far.

    I basically use partial classes to split up the domain service class into separate logically grouped classes/files. That makes is easy to find and edit everything to do with a specific area. The entities (or models as I call them) are then all put into a separate folder to keep them together.

    In a typical order management system you might have Customers, Orders and Invoices and my layout would look as follows:

    Acme.OrderManagement.csproj

    - Ds.cs // main domain service partial class with initialization, dispose, count override, etc
    - Ds.Customers.cs // query, insert, update, delete methods related to Customers in partial class
    - Ds.Orders.cs // query, insert, update, delete methods related to Orders in partial class
    - Ds.Invoices.cs // query, insert, update, delete methods related to Invoices in partial class

    Models // sub-folder
    - CustomerModel.cs       // Customer model/entity class
    - OrderModel.cs             // Order model/entity class
    - InvoiceModel.cs          // Invoice model/entity class

    If I uses digest objects (small entities only used for populating grids/tables) then I will create a separate Digests folder as a sibling to the Models folder and put them all in there. So you might have CustomerDigest.cs, OrderDigest.cs and InvoiceDigest.cs in there.

    If you have more than one domain service in the class library project then you can move all the above down one level with a new set of folders in the root where each folder contains a separate domain service.

    When using folders I also use the folder name as part of the namespace.

    Hope this helps.


    Regards, Xander. My Blog


    • Edited by novascape Wednesday, May 21, 2014 12:18 AM formatting
    Wednesday, May 21, 2014 12:11 AM
  • Does only your main class Inherit DomainService?


    Simon Jones
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.

    Yes, the other classes inherit from the main class.

    Don't worry about this, it's not preventing me from doing anything - I just wondered.

    • Edited by Hessc Wednesday, May 21, 2014 3:39 AM
    Wednesday, May 21, 2014 3:38 AM
  • Is this the problem. Is LightSwitch treating every class that inherits DomainService as a possible Data Source, even if they don't directly inherit it?

    I'm not saying this is the answer, just that it strikes me as possible.


    Simon Jones
    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, please remember to "Mark as Answer". This will help other people find answers to their problems more quickly.

    Wednesday, May 21, 2014 9:42 AM
  • If the Main class inherits from the Domainservice class and all the other classes then inherit from the Main class then all those other classes will definitely also show up as data sources when attaching the data source in LS.

    Using the concept of partial classes like I described above overcomes that issue.


    Regards, Xander. My Blog

    • Proposed as answer by Simon Jones [MSDL] Wednesday, May 21, 2014 4:28 PM
    • Marked as answer by Angie Xu Tuesday, June 3, 2014 8:09 AM
    Wednesday, May 21, 2014 11:01 AM
  • I have not tried it yet, but I have no doubt that partial classes will solved the issue I described.  I will post back if not.  Thanks. +1
    Wednesday, May 21, 2014 5:10 PM
  • Hello Hander,

    I was on vacation a few days. Many thanks to all replies. The big, big problem is that I cannot refactor the WCF RIA Project.
    To understand this problem, here are the details:

    I followed the article of Eric Erhardt at http://blogs.msdn.com/b/lightswitch/archive/2011/04/08/how-do-i-display-a-chart-built-on-aggregated-data-eric-erhardt.aspx
    and I created a class library project to query the:  WCF RIA Service (at the begin I used VS 2012, but I could successfully upgrate the solution to VS 2012 Update 4, so I have now LightSwitch v3.0).

    My main class is ReportingService.cs and inherits from DomainService (public class ReportingService : DomainService).
    The problem is, that I have nested classes (i.g. many classes and private methods within the ReportingService.cs) and I want to refactor and separate the classes and methods.
    At this moment there are not problems by building the solution and everything works as expected and correct.

    But when I try to refactor and put this "many classes" outside the ReportingService.cs I cannot build the solution anymore.
    The error is:
    Could not copy the file "C:\TFS2012\PersonalManagement\PersonalManagement\Dev\Sources\PersonalManagement\PersonalManagement\Server\obj\Debug\Application.Server.dll"
    because it was not found. 
    C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\LightSwitch\v3.0\Microsoft.LightSwitch.targets 108 6 PersonalManagement

    PersonalManagement.ls3proj failed.

    Please help, what can I do in this situation?

    I don't have another Domain Service class in the class library project.

    Should I make the ReportingService class partial? And after that which is the next step?

    @Simon:

    Only the ReportingService.cs inherits from DomainService.

    Many, many thanks. A prompt reply would be great! 

    Tuesday, May 27, 2014 9:59 AM
  • Hey Xander,

    is Customers.cs (query, insert, update, delete methods related to Customers in partial Ds.cs class),  a nested class within the partial class Ds.cs?

    Thanks for the answer.

    Tuesday, May 27, 2014 2:26 PM
  • There is no Customers.cs in the example above, only a Ds.Customers.cs and it is a partial domain service class and not a nested class. There are no nested classes.

    The reason for using partial classes in my pattern is to allow you to split the domain service class into multiple files to make it more maintainable.

    So you would have the following for the domain service partial classes:

    Ds.cs
    public partial class OrderManagementDomainService : DomainService
    {
    // initialization, count, etc
    }

    Ds.Customers.cs
    public partial class OrderManagementDomainService
    {
    // public query/update/insert/delete methods for CustomerModel
    }

    Ds.Orders.cs
    public partial class OrderManagementDomainService
    {
    // public query/update/insert/delete methods for OrderModel
    }

    Ds.Invoice.cs
    public partial class OrderManagementDomainService
    {
    // public query/update/insert/delete methods for InvoiceModel
    }

    And then for the model entities:

    CustomerModel.cs
    public class CustomerModel
    {
    // public properties for Customer model
    }

    OrderModel.cs
    public class CustomerModel
    {
    // public properties for Customer model
    }

    InvoiceModel.cs
    public class InvoiceModel
    {
    // public properties for Invoice model
    }



    Regards, Xander. My Blog

    • Edited by novascape Tuesday, May 27, 2014 9:27 PM
    • Marked as answer by Angie Xu Tuesday, June 3, 2014 2:30 AM
    Tuesday, May 27, 2014 9:25 PM
  • Hello Xander,

    thank you very much for for contribution.

    Tuesday, June 3, 2014 7:23 AM