For an application with more than a few tables, the default domain service class that is generated by the RIA services wizard is going to become unwieldy at best. I'm wondering how everybody else has structured their domain service class(es).
I already have my application split into modules (using Prism2) so I have decided to have one DomainService for each module. I do have some entities that are duplicated across multiple modules/DomainServices so I have created interfaces for those entities
so that I can reuse code more easily. That isn't really my recommended pattern, it is just what works best for my particular system.
My general recommendation is that you use a single DomainService split up using partial classes so that every entity is in a seperate file. That makes it easy to regenerate a single Entity using the wizard is you wish and generally makes things easier to
manage. All you have to do is generate multiple DomainServices, one for each entity, and then change the class definition so that they are all partial classes of the same DomainService.
Colin, regards to first part of your answer, are there any changes with latest WCF Ria? I'm trying to use Prism 2 with these methodology. But I have a question: what about code reusability? Even with interfaces I have to write the same code over and over again
for same entities. Regards to second part, in this case we must put all controls in a single project otherwise we must incur in error "The type [DomainContext] exists in both [ProjectA] and [ProjectB]. Am I correct or I miss something? I am very new with Silverlight,
WCF RIA and PRISM but it seems to me that there are not GOOD approches in use of Domain Service with large application.
By only spending some time with the project and get all the facts about it, someone can decide the best way to architect the app. Everything depends on! There is no Silver bullet.. So for example Colin uses one solution in his project. Trying to find the
Silver bullet is like digging your own grave... there is no one.. You have to get the whole picture of the apps, who will use it, how many will use it.. what are our resources.. how is the network between the client and server, how much data can we send and
so much more. But to give you some examples.. I have done something similar to Colin, but often use DTO (I guess he passes DAL types ;)), I create a DomainService for each View.. to only give the view what it needs. I have also done one DomainService per module
as Colin in another project.. One thing to have in mind is that RIA Services don't support entities cross DomainServices. For larger project I see the DomainService as my window to my business logic.. so I would never pass DAL types or adding business logic
into my DomainService..
Fredrik, what you wrote is correct. I wrote some example in both ways for my test app but I found no one to adapt to me. I wrote app with one domain service on server side and a single project on client side: this means (in my very poor experience) one big
app on client hard to maintain. I wrote app with multiple domain service on server side ad multiple projects on client side: very easy to maintain client side but hard on server side. E.g.: I have on my DB a table Cities; it's referenced by the table Persons
(wich have its project and controls on client side) but also by the table Addresses (wich have its own project and controls) and suppose by other 3/4 tables in DB. What if I add or remove a field on Cities? I must change Persons domain service, Addresses domain
service and the other 3/4. Probably it was me but I never read posts nor saw webcast on domain service with large application. OK: no silver bullet.. but a lead bullet for me would be enough!
About the Cities.. With RIA Services you can't have entities cross domain services.. So you can't have a DomainService for the Address, one for the Person and both reference to the City entity. But about the problem you describe, that same problem would
be in your business logic too. If you aren't interested to show the added field or the removed field in the views.. you can use a model for the presentation (for example a DTO), and the DTO will not care about the removed field or added field because it isn't
used on the View.. so your DomainService returning the DTO don't need to use the added or maybe don't care about the removed field on Cities. As more dependencies you have, as more you may need to change based on one single change.
Fredrik -> "With RIA Services you can't have entities cross domain services" That's because you must use an "all-in-one" solution.. and that's why I am going to build a multi domain service application. IMHO this could be the right way to build large application
in an organized way. Fredrik -> "As more dependencies you have, as more you may need to change based on one single change." It is my point for multi domain service application. You have to admit that it is not an optimum solution. I thought it was my lack
of experience but I find it is the way WCF RIA works. PS: Quoting here dosen't work the way I expected. I use Chrome on a Mac.
samw
Member
164 Points
282 Posts
Best way to architect DomainServices classes for a mid-size/large application?
Jul 20, 2009 03:27 AM | LINK
For an application with more than a few tables, the default domain service class that is generated by the RIA services wizard is going to become unwieldy at best. I'm wondering how everybody else has structured their domain service class(es).
Klinger
Participant
1676 Points
300 Posts
Re: Best way to architect DomainServices classes for a mid-size/large application?
Jul 20, 2009 04:35 AM | LINK
Our app has more than 100 tables.
The wizard generated class is just your starting point. You don't even have to use the wizard if you don't want to.
The way we are doing it, so far, is:
1 - Used the wizard to generate the first domain service class and all the metadata classes.
We decided to go with only one domain service.
2 - Made the domain service class a partial class and separated the entities in multiple files.
Those files contains the original CRUD methods.
3 - Separated the metatada classes in multiple files (by subdomain)
4 - Additional Read operations are created in a different Domain Service file.
For small changes on the database we just edit the domain service file(s) and metadata file(s).
Even for a big change we would consider doing all the changes manually.
We may use the wizard, giving a different domain service name, and than pool manually what we need.
Instead of having only one domain service you could divide your entities in multiple domains and deal with
the domain context linking on the client.
Dealing with transaction involving multiple domains services is probably more challenging than going with just one domain
service.
Klinger
ColinBlair
All-Star
28591 Points
4834 Posts
Re: Best way to architect DomainServices classes for a mid-size/large application?
Jul 20, 2009 05:03 AM | LINK
I already have my application split into modules (using Prism2) so I have decided to have one DomainService for each module. I do have some entities that are duplicated across multiple modules/DomainServices so I have created interfaces for those entities so that I can reuse code more easily. That isn't really my recommended pattern, it is just what works best for my particular system.
My general recommendation is that you use a single DomainService split up using partial classes so that every entity is in a seperate file. That makes it easy to regenerate a single Entity using the wizard is you wish and generally makes things easier to manage. All you have to do is generate multiple DomainServices, one for each entity, and then change the class definition so that they are all partial classes of the same DomainService.
http://www.RiaServicesBlog.net
ColinBlair on Twitter
MVVM and RIA Services
angelochiello
Member
13 Points
24 Posts
Re: Best way to architect DomainServices classes for a mid-size/large application?
Jan 12, 2010 10:05 AM | LINK
hectorluis.c...
Member
2 Points
1 Post
Re: Best way to architect DomainServices classes for a mid-size/large application?
Jan 12, 2010 10:29 AM | LINK
Very nice post
Fredrik N
Contributor
5184 Points
785 Posts
Re: Best way to architect DomainServices classes for a mid-size/large application?
Jan 12, 2010 10:42 AM | LINK
By only spending some time with the project and get all the facts about it, someone can decide the best way to architect the app. Everything depends on! There is no Silver bullet.. So for example Colin uses one solution in his project. Trying to find the Silver bullet is like digging your own grave... there is no one.. You have to get the whole picture of the apps, who will use it, how many will use it.. what are our resources.. how is the network between the client and server, how much data can we send and so much more. But to give you some examples.. I have done something similar to Colin, but often use DTO (I guess he passes DAL types ;)), I create a DomainService for each View.. to only give the view what it needs. I have also done one DomainService per module as Colin in another project.. One thing to have in mind is that RIA Services don't support entities cross DomainServices. For larger project I see the DomainService as my window to my business logic.. so I would never pass DAL types or adding business logic into my DomainService..
MVP, ASPInsider, WCF RIA Services Insider
My Blog
angelochiello
Member
13 Points
24 Posts
Re: Re: Best way to architect DomainServices classes for a mid-size/large application?
Jan 12, 2010 11:28 AM | LINK
Fredrik N
Contributor
5184 Points
785 Posts
Re: Re: Best way to architect DomainServices classes for a mid-size/large application?
Jan 12, 2010 11:51 AM | LINK
About the Cities.. With RIA Services you can't have entities cross domain services.. So you can't have a DomainService for the Address, one for the Person and both reference to the City entity. But about the problem you describe, that same problem would be in your business logic too. If you aren't interested to show the added field or the removed field in the views.. you can use a model for the presentation (for example a DTO), and the DTO will not care about the removed field or added field because it isn't used on the View.. so your DomainService returning the DTO don't need to use the added or maybe don't care about the removed field on Cities. As more dependencies you have, as more you may need to change based on one single change.
MVP, ASPInsider, WCF RIA Services Insider
My Blog
angelochiello
Member
13 Points
24 Posts
Re: Re: Best way to architect DomainServices classes for a mid-size/large application?
Jan 12, 2010 01:38 PM | LINK