Something that frequently bothers me is when people/companies create services that are basically thin layers on top of their database. The service contracts expose the typical CRUD operations for each table, and add some additional methods for specific queries etc. These kind of services will sometimes pretend to contain a bit of ‘business logic’ but they are essentially just a remote interface into your database with maybe a bit of extra security on top of it. They effectively turn your database into a remote service. Now if you’re anything like me, you’re probably thinking “why on earth would people do that?”
There are probably a few answers to that question, but one reason that can’t really be disputed is that a lot of the tooling that Microsoft offers to developers simply encourage this kind of stuff. Let’s go over a little example.
I wanted to see what some of Microsoft’s recommended tools would create for me if i wanted to create a Silverlight application which uses a database. Obviously, a Silverlight application can’t use a database directly so the application will need to communicate with a service. The service obviously does have access to the database. RIA Services is a solution that Microsoft seems to be pushing a lot for this specific scenario so i figured i’d give this a shot.
I created a RIA Services Class Library project in my solution and tried to add a ‘Domain Service Class’ (as the RIA Services templates call it) to the project. If you already have a DataContext or an ObjectContext defined within the same assembly, you can immediately select the database tables that you want to expose. So i canceled the dialog and quickly added an ADO.NET Entity Data Model to the solution for which i selected my Chinook database. I tried to create a ‘Domain Service Class’ again and got the following window:
Well, now that sure is easy isn’t it? I can immediately select all my ‘Entities’ and i can even check whether i want to be able to edit them through the service, and apparently i can also generate associated classes for metadata (which would be useful for validation according to the tooltip). I checked the Album table, and left the ‘Enable editing’ option unchecked. This created a service with the following code:
// Implements application logic using the ChinookEntities context.
// TODO: Add your application logic to these methods or in additional methods.
// TODO: Wire up authentication (Windows/ASP.NET Forms) and uncomment the following to disable anonymous access
// Also consider adding roles to restrict access as appropriate.
// [RequiresAuthentication]
[EnableClientAccess()]
public class AlbumService : LinqToEntitiesDomainService<ChinookEntities>
{
// TODO: Consider
// 1. Adding parameters to this method and constraining returned results, and/or
// 2. Adding query methods taking different parameters.
public IQueryable<Album> GetAlbum()
{
return this.ObjectContext.Album;
}
}
I don’t know about you, but i love those TODO statements. After all, you really do might want to consider constraining the resultset that could be returned by the GetAlbum method. Who knows, perhaps you have certain use cases where you don’t want all of the ‘entities’ in the Album table to be returned by your ‘domain service’. Hopefully, this service will be used by developers who are smart enough to realize that they should modify this method, instead of using client-side LINQ statements to filter the returned Album ‘entities’ as i’m sure we’ve all seen in too many Microsoft demo’s already.
It gets better if you recreate the service and check the ‘Enable editing’ option. Now you’re ‘domain service’ will also contain the following methods:
public void InsertAlbum(Album album)
{
this.ObjectContext.AddToAlbum(album);
}
public void UpdateAlbum(Album currentAlbum)
{
if ((currentAlbum.EntityState == EntityState.Detached))
{
this.ObjectContext.AttachAsModified(currentAlbum, this.ChangeSet.GetOriginal(currentAlbum));
}
}
public void DeleteAlbum(Album album)
{
if ((album.EntityState == EntityState.Detached))
{
this.ObjectContext.Attach(album);
}
this.ObjectContext.DeleteObject(album);
}
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?
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? And those TODO statements simply won’t cut it, you know that all too well. 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.
The only benefit that i can see from using RIA services is that you don’t really have to deal with your service contracts, and your operation contracts or any of that stuff. No, we won’t be doing any of that. We simply use a [EnableClientAccess] attribute and we’re done! I don’t really consider that a benefit, though i can certainly understand why people would not want to deal with the pain of classic WCF services. RIA Services is simply a solution to the wrong problem.
I haven’t looked at ADO.NET Data Services (which will be renamed to WCF Data Services in .NET 4.0) yet, but i suppose it’ll be more of the same: something that makes it incredibly easy to create services directly on top of your database data.
Seriously though: who on earth actually wants that?
I have no doubt that there are some people out there that are using RIA Services in a responsible manner and are sticking by responsible architectural guidelines. I also have no doubt that those people are ignoring most of the tooling that is offered by Microsoft around it. So really, why not get rid of this kind of tooling, and spend the effort that normally goes into those tools (or anything else which encourages bad practices for that matter) on providing actual guidance to the developers of your platform? The last thing we need are more developers who think that this is ‘ok’, or projects that have been delivered based on this kind of ‘architecture’, or customers that are turned off by .NET projects because “they all have maintenance problems”.
Pingback: The Morning Brew - Chris Alcock » The Morning Brew #519
Pingback: Learning Silverlight #3 – Getting Started « Danny-T.co.uk home of Dan Thomas, Moov2 Ltd