Entity Framework with RIA services, Silverlight - tradeoff of decoupling versus rapid development

I've been playing around lately with Entity Framework, WCF RIA Services, and Silverlight 4. I'm impressed by how rapidly you can develop an application with these tools, and you get a lot "for free", such as the Silverlight UI automatically knowing about certain validations that are included as DataAnnotations on the EF model. However, it seems like in a large application it would b开发者_如何学Ce undesirable to have a dependency on EF pushed all the way through the entire application including the business logic and UI.

I know that you can use POCO / IPOCO with Entity Framework, and that is certainly an option for me. However, if you go that route, you lose some of the "automagic" stuff such as Silverlight being able to show model validations without any extra work.

How are people dealing with this? Do you give up some of the power and put interfaces in between the different layers in order to decouple the other layers from EF? Or do you give up on decoupling in order to allow for more rapid development? Is there some way to have my cake and eat it too that I'm not seeing?

My group is currently dealing with this exact issue. We came up with a decent compromise that everyone was happy with. Keep in mind that before it is all over with, projects become more complicated over time and maintainability is key. You also want to increase code reuse as much as possible so replacing your UI (or unit testing) is a minimized effort.

Given all this, we favored a well defined domain layer instead of pushing EF all the way through to the UI. This makes the model the heart of the application and doesn't force us to conform to the schema of our database. I know EF tries to abstract that away with its conceptual model, but we kept running into little gotchas that made it more and more difficult to rely on EF for the full stack. For instance, there really isn't a great place to put business logic with EF. We didn't want to put that stuff into Interceptors and we didn't want to put it in the UI. Sure, there might be a clever workaround for this, but we weren't liking the direction we were being pushed.

The compromise was to use EF but to keep it between the data store and the domain model. This way we still don't have to program against DataReaders, and we can leverage the benefits of self-tracking entities in the domain. We then expose basic WCF services (not RESTful) from our domain to our UIs.

To us, the extra validation work wasn't really THAT big a deal. Sure, our initial release takes a little more time, but the overall maintenance cycle doesn't take as long because we aren't finagling with the complexities of the framework.