How much business logic belongs in RIA services layer?

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 u开发者_运维问答se 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?

Our team is in the process of implementing a Silverlight app on top of the RIA stack. We've decided to build a domain model on top of the RIA entities. Additionally, we elected to follow the MVVM pattern to model UI interactions.

So far, I've noticed the following benefits:

1. Domain classes are a nice place to put business logic including complex validations.
2. Domain classes use the RIA entities and context as interface to data store.
3. Domain classes are modelled after business concerns and do not require a one-to-one relationship with RIA entities.
4. Simple UI validations can live in the ViewModels.

Another thing to note is we've implemented our own identity map for concurrency and pushed off dirty tracking to the RIA context.

In practice, this architecture requires a bit more coding effort, but pays off big time with readability and maintainability. Even for simple CRUD applications, I'd follow this practice. Having the ability to build a domain model that more accurately represents the problem space is a compelling advantage.

In general it is more productive to work with the technology than against it.

As you say the business logic ends up in DataAnnotations and custom validations, this may be the "best" place for it with respect to developer productivity, for the first version of the system.

I have a feeling that this technology has it's strength when rapidly building crud applications, when you have complicated business logic you may end up with an extra business layer in between the silverlight application and the RIA services.

Have not tried to build anything real in this yet, we will only really know the answer to this after we have used it for some time.