Some developers consider that Microsoft's RIA Services code-generating tools are teaching bad architectural principles to developers while others consider the tools useful if used properly.
Very simple applications can be built up rapidly without much thought given to their architecture. The presentation layer could access the database directly since there would be almost no business logic involved. But what happens if the application grows in complexity adding more and more business logic? Should the presentation layer be let to access the database directly? Solid architectural principles say “No” because such an approach introduces strong links between the two layers so a simple change in one of them has rippling effects in the other.
Microsoft technologies are known for offering code generating tools that make the life simpler for the developer at least at the first glance but are not really useful for large projects, and they are considered by some to teach bad lessons to new developers. RIA Services tools are no exception.
The RIA Services Class Library project in Visual Studio generates the services necessary to access a database. While this sounds like a great idea, the simple code it generates may give the impression that it is OK to access those services directly from a client application, for example from Silverlight. So instead to create high coupling between the client application and the database, now one can have high coupling between the application and services which behave like a remote interface to the database. Davy Brion, a .NET developer committed to NHibernate and Agatha projects, has used VS to generate DB access services and remarked:
Man, this sure is easy, isn’t it? I now have a service that offers me full CRUD access to the Album table in my database. If i wanted to, i could now start implementing a screen in my Silverlight application which allows my users to list the albums, edit them, delete them, create new ones, etc… and i wouldn’t even have to change anything in my ‘service layer’. The problem is that too many developers actually will do exactly that. After all, why should they doubt any code that was generated by a tool which comes from Microsoft? If the tool can generate this, then certainly some people actually want you to use it like this, no? If not, why would it even generate code like this?
But Brion does not think the basic services created by VS are such a great idea:
I’m sure this kind of stuff gets a lot of ooh’s and aah’s during the product demo’s at Microsoft events, but other than that, what good does this really bring? Is this really the way you want people to develop their services? Do you really want developers to pretty much expose the database as-is to remote clients? … I simply don’t think there’s any good reason to generate code like this because a lot of people will simply take it as is and use it like that directly from their client code. Oh sure, most of them will hook up the authentication but I’m willing to bet that very few people will actually put real business logic in there. Why would they? The message that a lot of people will get from the resulting code is that a service is merely a way to provide CRUD for your database tables. What’s business logic to these people? Right, the stuff they’ll implement in their presentation layer because this service doesn’t really encourage people to consider implementing it there.
Jeffrey Palermo agrees with Brion and explains why he thinks Microsoft creates such tools:
Microsoft has a history of creating tools which are easy to use. I agree with you about the architecture principles, and I advocate dodging the out-of-the box architecture in favor of better maintainability. The Microsoft platform is widely adopted because it is easy to get started. It is actually a good business decision. Once customers become more educated they will eschew the default coupling conventions and put better design in their apps. Before that, at least they are able to get some software. When the alternative is no software, the Microsoft tooling is welcome assistance.
Eric Hauser commented on Brion’s post mentioning that WCF Data Services allows the developer to automatically create services over domain objects, so one does not necessarily need to create them over a database:
Data Services also has reflection based provider that you could use to expose your domain model (not your database) as services. I am currently writing a custom provider (using the 1.5 update) that allows us to load metadata on the fly and generate different web services depending on customer customizations. There are certainly limitations to the model.
Bruce, another developer, considers that WCF RIA Services does not prevent developers from applying sound architectural principles:
A lot of developers may use WCF RIA Services unwisely. On the other hand I think that a lot of developers will use WCF RIA Services wisely.
The good thing about WCF RIA Services is that it provides a place (your domain services classes) for you to add business logic that is separate from your presentation layer, and it provides a great deal of flexibility for you to structure your business interface and logic however you want.
Therefore I see no reason why you can’t define a sound architecture using WCF RIA Services, and implement it productively.
What is your opinion on this? Are Microsoft RIA code-generating tools useful? Do they teach developers bad architectural practices? Can they be used in a good way?