What are the advantages and disadvantages of single/multiple domainservices in RIA

Question

When using the RIA services in Silverlight, I am wondering what is the best solution for numbers and organization of domainservices?

I have read some articles about this With many different statements, and found that some prefer:

• One domainservice per viewmodel
• One domainservice per Group of Objects (ie. orders, orderlines, Products etc.)
• One domainservice for the Whole Application

and some more...

I think there are pros and cons on all different solutions, but I would like to hear if anyone has some real-life experience with this?

Any sharing of knowledge/experience is appreciated, as we are considering to rewrite/restructure the database layer of a major business Application.

Answer 1

I've never heard of "One domainservice per viewmodel", and I think it's against how RiaServices is designed.

One DomainService per group of objects is probably the way to go if you have to deal with a large domainmodel. Take into account, however, that you'll get troubles when you 'll have to submit change for entity that belongs to two different domaincontext (i.e. Orders and Customers) in a single transaction: you'll have to call two different SubmitChanges.

One DomainService for the whole application is definitely the way to go if your application it's not that big (I'll say < 100 domainmodel classes)

Answer 2

The official guidance is that the DomainService, DomainController (future),and DomainContext represent a single unit of work. Anything that needs to be saved together as a single transaction must be in the same Service/Controller/Context so that is the minimum size and scope. There is no official guidance for maximum size, however thinking in units of work can help guide that as well. If you have two different screens of data that can save independently of each other then you probably want two separate contexts so that an error in one screen doesn't prevent the other screen from saving.