Help with structuring a Telerik OpenAccess Domain Model

Question

My company is about to start a new project using Telerik's OpenAccess ORM. This is a new product to us, and the first time we'll be using an ORM for a project instead of a Dataset based approach. We are currently having some disagreement regarding the best way to structure our data layer. Specifically, should we have a single .rlinq file and domain model for the project, or should we have per screen/module .rlinq files that contain only the tables, and the columns from the tables, required for that particular screen/module. To illustrate the latter:

Say we have a Person table, with fields for first name, last name, ssn, birthdate, gender and marital status. In the personal information screen, we need all of these fields, so we include the whole table in the domain model in that .rlinq file. On another screen (with a separate .rlinq file), we only need the person's last name and ssn, so the Person object in that .rlinq file contains only last name and ssn.

The argument for this method has been primarily that we should only select the data that we need for a particular screen, and no more. In our current Dataset based applications, this makes sense. There has also been concern expressed that having unnecessary tables and relationships will cause unneeded data to be loaded even if it is not asked for and lead to network load. The argument against this has been that we're fragmenting the domain model and introducing unnecessary complexity, and that part of the job of the ORM is to manage data fetching with caching and lazy loading. We can't come to an agreement on this, and can't find any conclusive information one way or another, so we're turning to the StackOverflow community for help!

If it matters, we're building a Windows Forms based intranet app, and the data layer will be sitting behind WCF services, and the database will have around 100 tables.

Thank you in advance for your help!

Answer 1

In general it is best to have a solid domain model built up in a single RLINQ file. You can then handle screen concerns by projecting queries into ScreenModels/DTOs as needed.

For Example

Say you have a person object with multiple properties, however, on a particular screen you only want to return first name & last name.

   var myUserDto = context.People
                          .First()
                          .Select( p => new UserDto { FirstName= p.FirstName, 
                                                      LastName=p.LastName });

OpenAccess is smart enough to only query for the first/last name in this case. Now when the screen ends up requiring another property available in the person object, you only need to update the dto and LINQ query.

Also, if you plan to use the Data Service Wizard OpenAccess provides, it creates a service per OpenAccessContext. So if you have an RLINQ per entity you will have a service per entity, which would be painful to maintain on the client to say the least. If you hand roll the service layer, you would obviously have a little more control here, but you will still need to constantly remember which OpenAccessContext handles each domain object.

FYI, For a large model it may be helpful to look into the aggregate metadata source OpenAccess provides to help break up large models into manageable pieces.

Hope this helps! :)