How much business logic belongs in RIA services layer?
- by jkohlhepp
I have been experimenting recently with Silverlight, RIA Services, and Entity Framework using .NET 4.0. I'm trying to figure out if that stack makes sense for use in any of my upcoming projects. It certainly seems like these technologies can be very productive for developing applications, but I'm struggling to decide how an application on top of this stack should be architected.
The main issue I have is that in most of the demos I've seen most of the business logic ends up as DataAnnotations and custom validations in the RIA Services domain service class. This seems inappropriate to me. I view the domain service as basically a glorified web service that happens to make it easy to push information to the client. But most of what I've seen seems to orient the domain service as the main source of business logic in the application.
So, my questions:
What is the best location for business logic (rules, validations, behaviors, authorization) in an application using this stack?
Are there any guidelines published at an architectural level for using this stack?
My questions pertain to large, complex, and long-lived applications. Obviously for an application of only a few screens this is less of a concern.
Edit:
Another thing I meant to mention is that obviously you can make the domain service class stupid, but then you lose a lot of the automagic entity information (e.g. validations) being pushed to the client. And then if you lose that is there any point to using RIA services?
