I submitted an article recently to The Code Project on how to use a GridView control in a Business Layer. The article and accompanying code demonstrates a way to use the GridView control with a business layer. Though I’ve been using that solution in several projects successfully for several months now, I’m still bothered by the baroqueness of it all. When I started out, I really just wanted to bolt the Grid control onto a generic list of business objects. One by one, I encountered various roadblocks. First, the elements in the list had to be Serializable, and of course in a rich domain model this means practically the whole business layer has to be declared Serializable. Then the ObjectDataSource had to get it’s data from a stateless class. Then I couldn’t use static methods in the ObjectDataSource. Etc, etc, etc.
The main thing that led me to the adaptor solution was the feeling that I didn’t want a display component (namely the GridView/ObjectDataSource) putting such deep requirements on the business layer. While these requirements are probably not a problem with very thin business layers, I tend to favor rich domain models where the requirements are coming primarily from the business domain. So I developed a solution where a copy of the business data could be maintained in a thin layer of adaptors that encapsulate completely the rules for synchronizing with their respective domain objects, but don’t contain any business logic themselves. I found that this allows me to keep the business logic properly in the domain objects, but also facilitates exchange with other services, like importing data from off-project external databases, as well as driving display components like GridView .
A popular (or famously unpopular depending on your point of view) alternative to rich domain models are the anemic domain models in which the business logic is maintained primarily outside of the business layer in service layers, and the domain objects are thin repositories containing only data. While Martin Fowler points out correctly that this violates the spirit of OO programming because “it’s so contrary to the basic idea of object-oriented design; which is to combine data and process together,” I have to wonder if one of the drivers of anemic domain models is precisely this kind of ease in hooking up thin business objects to many different services.
The GridView with SQLDataSource strikes me as the archetype anemic domain model. Business logic is essentially kept in stored procedures or dynamic SQL statements. The requirements of the ObjectDataSource seem to thrust a a similar anemic domain model on the developer, which was the source of my initial discomfort. Adaptors are a way to keep the rich domain model and have the benefits of easily linking to services.
So the solution using adaptors probably should have been called “Getting GridView to work within a rich domain model”. And the baroqueness of the solution disappears when you widen the scope of undestanding from “How do I get the GridView to work with a List<>?” to “How do I get the GridView to work with a rich domain model?”
(Updated 4/22/2007 10:00 PM: The initial placeholder post was replaced with a real one ;-)
(Updated 4/24/2007 5:00 PM: The article was posted on the Code Project, and link provided above.)
