Debate: Microsoft’s RIA Services Code-generating Tools and Sound Architectural Principles

Posted by Abel Avram on Jan 28, 2010

Sections

Development

Topics

Tools ,

Rich Internet Apps ,

.NET

Tags

Debate ,

Visual Studio ,

Services

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?

1. Back to top

   Code generating tools

   by Andrew Garner

   I think the tools are useful for quick development of prototypes, but I agree they can easily be abused by inexperienced/lazy/under-pressure developers. I currently maintain an application with generated database code using typed datasets. It's the bane of my life and so much harder to update and modify than data access code using NHibernate.
   I also think that all this generated code can mean that it's easy to not learn how to do things properly or how to use the technology.

   Reply

2. Back to top

   Re: Code generating tools

   by Ben Pittoors

   If you want a quick prototype you don't use a service layer. You use mocked data.
   
   IMO there is absolutely no reason for a code-generated services layer on top of a database.

   Reply

3. Back to top

   Code generating tools

   by Sean Capes

   Personally I don't see a problem with this approach. It gives a quick start approach to building an application with much of the plumbing hidden from developers, after all we've supposed to be focusing on the customer value and not just technology.
   As the requirements and complexity of the application evolves, so should the technology. As mentioned there are clearly defined points that allow for decoupling of the presentation layer by using the service interfaces to hide the business logic. This can be applied over time. Surely trying to pre-empt all of this goes back to the up front approach?
   No tool or technology will counter bad developer practice, but many tools improve productivity through careful application. I think this is one such candidate. In my opinion, managing complexity is one of the hardest challenges of software development, and if we can use consistent patterns, tools and technology to assist with that, we should.

   Reply

• Older >