CODEWITHSUNDEEP
c#silverlightc#-4.0silverlight-4.0
TCM
TCM

Reputation: 16900

Best practises for creating RIA services DomainContext

If you refer any MVVM samples of Silverlight developed, you will find that each ViewModel has it's own DomainContext. However, I don't really see the need to have ViewModel specific DomainContext.

I tend to create a shared DomainContext for all ViewModels. That way when the problem of adding an entity into a different DomainContext and delete it from different DomainContext never comes. Otherwise it may happen you are trying to delete from a DomainContext that doesn't have that specific entity at all and so exception..

Can anybody tell me what does the best practises say for DomainContext?

Upvotes: 2

Views: 947

Answers (2)

Gayot Fow
Gayot Fow

Reputation: 8792

My two textbooks on MVVM, which are...

Building Enterprise Applications with Windows® Presentation Foundation and the Model View ViewModel Pattern by Raffaele Garofalo

Pro WPF and Silverlight MVVM Effective Application Development with Model-View-ViewModel by Gary McLean Hall

...do not address the DomainContext directly. However, both authors agree that where the Data Access Layer is concerned the 'Unit of Work' design pattern is recommended. If you contemplate using one or more DomainContext(s) in a SL application as part of your Data Access Layer, you would be advised (by these authorities anyway) to consider encapsulating them into a 'Unit of Work' pattern. Let your ViewModel deal with these abstractions.

As to best practices, I think you have satisfied 'best practices' when these patterns have been diligently considered. Implementing them could be overkill for many situations.

There is an introduction to 'Unit of Work' at http://msdn.microsoft.com/en-us/magazine/dd882510.aspx

Upvotes: 1

Xcalibur37
Xcalibur37

Reputation: 2323

There are many ways to go about it, so the best I can do is share what I do.

1) Create each domain context based on function. For example, I will have a context for all User functions, one for all Customer functions, one for Order functions, etc. This allows for clean BusinessLayer segmentation.

2) Create custom classes in the Web project that will be returned instead of the abstracted views created by the wizard. I personally have an issue with having the name of my DB View specified in the IQueryAble returned to the Silverlight project, since the Silverlight project can be considered the UI layer. It forces a dependency on the DataLayer indirectly, which we don't want. Yes, it creates more work with adding additional classes, but it helps enforce abstraction for a proper 3-layer architecture.

3) Create custom classes on the UI layer that digest the returned data from the mapped methods (from the DataContext). This helps enforce abstraction.

Remember, the end goal is to make your code as loosely coupled as possible. That always requires additional (and sometimes redundant) coding on your part, but the end result is worth the efforts.

You can also consider creating a RIA Class Library; which allows you to abstract further. It's not the simplest implementation, but it's a step in the right direction when attempting to facilitate communication between the Silverlight and Web Projects.

Upvotes: 1

Related Questions