What is the best method/technology to sharing the same data access layer between WPF, Silverlight, and ASP.NET?
I am using ADO.NET Entity framework, and was thinking of a creating a DAL using the Repository pattern.Then using the RIA Services as a dummy middle man to connect Silverlight and ASP.NET. Is this a solid plan or are there other better solutions out there?
Hello,
One of the solutions I like to use is the following : - Have a project storing only the entities (for example : Player, Game, Entity) with no reference to the database at all. - Have a project implementing the repository pattern (Repository, Repository etc...) - Use ADO.NET Entity Framework code first approach to map with the database (it creates a dynamic child object of your entities contain in your project, see ScottGu's blog for an explanation on how to use it)
Connecting Silverlight to your pattern can be done with Ria Services or classic WCF services. Usually I try to use WCF whenever possible as Ria Services is not really compliant with an MVVM development.
If you want to use WCF and share your DAL entities with Silverlight you can create a MyDal.Silverlight Silverlight class library project and add symbolic link instead of copies of every entities you will want to share with Silverlight. Then when you'll add a service reference with visual studio it will be smart enough to not create copies off Player, Game and User to you Silverlight project.
If you want to use Ria Services it will create copies of you entities anyway.
Hope that helps
John
RIA services will certainly take the burden off you for all the WCF plumbing. It has a few minor flaws (lack of certain data types), but there are workarounds for most problems.
The validation model (using attribute decoration and custom validators) is very strong and a great place to hang business rules.
RIA coexists happily with ASP.Net, so that is another plus. Behind the scenes it is just another WCF service. We are happily using RIA services with MVVM and Prism.
This is a tried and tested feature rich model. The only problems I have found related to many-to-many relationships. Again there are workarounds.
As RIA change sets are managed for you on anything, including POCO, this is the area that will need the most attention. It is considered "bad" to expose your EF model directly to RIA and that will certainly not insulate you from data changes.
I can't specifically recommend any one pattern yet (still experimenting), but make sure your choice is compatible with IQueryable. The paging feature and appending to Linq queries for server-side execution are features you do not want to lose!