I'm new to .Net RIA Services, but I think, its essence, is to target RAD what Microsoft usually cares about. But, does not that introduce more coupling between Presentation and Application/Business Logic? How can this new technology help increasing number of developers who are interested in OOAD Best Practices and concepts like SOLID, GRASP, and Design Patterns? Or there is a way to achieve both goals?!
views:
135answers:
3Does .Net RIA Services introduce a coupling between Presentation and Application/Business Logic?
I doubt that the authors of technologies such as this are attempting to increase interest in the design principles as such. The best we can hope for is that frameworks such as this may lead to development that conforms to Best Practices.
Your quesiton about coupling between Presentation and Business Logic, and whether RIA will tend to increase it is interesting.
We do need to define coupling quite carefully. What details of presentation logic must change if business logic changes? What changes in presentation requires changes in business logic.
To some extent any presentation layer, RIA or not, must change if the semantics of the business changes. So some kinds of coupling is unavoidable. However, well designed business logic will tend to support many different Presentations, but my suspicion is that sophisticated RIA apps tend to place greater requirements on the Business Logic.
So my guess is that .Net RIA will be doing what it needs to do to give the end-user experience we want to see. I don't believe that it forces un-needed coupling. Do you have particualr examples where you think undue coupling is resulting?
I've been dwelling on similar thoughts for the past few days now......I'm not entirely sure this will allow developers to retain the de-coupled approach either......examples to prove or disprove this would be awesome though!
It has a lot to do with what the developer shares between business and presentation layers. RIA Services does make it easy to give your presentation layer access to your Entity Framework classes, which obviously leads to coupling.
For developers with coupling concerns (should be everyone), it is also easy to define a model for communication between the business and presentation layers. The server side of RIA Services (which I would consider part of the business layer, because it's just a web service) knows how to build the model from your business objects. Silverlight only has to know how to consume the model and present it. That doesn't look like coupling to me.