Silverlight 4 - RIA Services - Is this good coding practice?

I'm pretty new to Silv开发者_运维问答erlight. I've spent the day looking at RIA services. The concept seems very nice and a way to save a lot of time writing data oriented Silverlight apps. However, in the time I spent with it, I came away with the feeling that many might feel the approach is too "quick and dirty" and would violate at least several best practices.

For example, by default, the back-end service layer doubles as the data access layer. And there seems to be tight coupling between database entities and the UI.

I'd be very interested in getting some comments from experienced Silverlight/RIA developers on these issues, and perhaps others I'm overlooking. I like the concept, but my concern is that those who are more code purists than I am would balk at this approach.

---

I think RIA Services encourages great patterns (save maybe for DomainDataSource, which many will use to put data access logic in the view, but I know the RIA Services folks have been looking at ways to make DDS be more MVVM-friendly). Here's some specific points I like about it from an architecture perspective:

• Validation logic can be stated once, but applied both client-side (nice UX) and server-side (security and consistency for non-SL clients of the service).
• Queries are executed cross-tier, so you can think about what you want/need on the client, formulate a query, and know that it will be translated all the way to your database without over-fetching. You can do all this without having to think about optimizing SQL queries and such, but get a lot of difficult-to-achieve benefits.
• By making everything bindable, it becomes much easier to use MVVM to keep your views simple and stupid. Data binding is your friend, and RIA Services makes it not so annoying/tedious to implement INotifyPropertyChanged over and over, plus it adds lots of other great harder-to-implement interfaces like INotifyDataErrorInfo (I think), and IEditableObject and so forth, which many Silverlight controls respect out of the box to "do the right thing".

I guess I don't follow what you mean by the service doubling as a DAL - the DAL is your model from LINQ-To-SQL or LINQ-To-Entities (or whatever DAL you like, NHibernate, etc..). The RIA Service is more of a business logic layer that sits atop the DAL, and exposes the data in a way that keeps the business logic consistent across consumers. In the case of Silverlight, it also adds the client-side codegen to do client-side validation and such, but that's just a value-add for Silverlight.

There can be tight coupling between the business entities and the UI, but this can be done with any technology. Exposing the right data, then building a UI on top of it, is something you have to think about regardless of technology.