As I was looking for another open source project for my refactoring series, I saw both, very good and very bad code.
As many projects, this one just wanted to implement three tiers, with the data and the business layer having their own data containers. Although they are equal by content, they are different classes.
I really don’t understand why anyone would do such a thing:
// In some method that needs an "Category" object
Category category = DBMapping(dbItem);
// Somewhere else, revealing what the dbItem is....
private static Category DBMapping(DBCategory dbItem)
{
if (dbItem == null)
return null;
Category item = new Category();
item.CategoryID = dbItem.CategoryID;
item.Name = dbItem.Name;
item.Description = dbItem.Description;
item.TemplateID = dbItem.TemplateID;
item.MetaKeywords = dbItem.MetaKeywords;
item.MetaDescription = dbItem.MetaDescription;
item.MetaTitle = dbItem.MetaTitle;
item.SEName = dbItem.SEName;
item.ParentCategoryID = dbItem.ParentCategoryID;
item.PictureID = dbItem.PictureID;
item.PageSize = dbItem.PageSize;
item.PriceRanges = dbItem.PriceRanges;
item.Published = dbItem.Published;
item.Deleted = dbItem.Deleted;
item.DisplayOrder = dbItem.DisplayOrder;
item.CreatedOn = dbItem.CreatedOn;
item.UpdatedOn = dbItem.UpdatedOn;
return item;
}
Doing so provides nothing, you just violate DRY and thereby create your self some great amount of repetive work. Further, human errors like forgetting a property will arise.
Another thing I encountered rather often is the following:
private IList<Category> GetAllCategories()
{
return DataLayer.CategoryManager.GetAllCategories();
}
The so called business layer is nothing more than a very thin proxy to the data layer. If you used interfaces for decoupling in both, the business and the data layer, you have to change 3 places in exactly the same way, doesn’t that feel just wrong?
If all you want to do is to allow different data stores, then just do that. There is absolutely no reason to duplicate your data containers in such a case.
You have at least three ways:
Let the different data layer implementations depend on the business layer. Define the data containers and the interfaces to retrieve those in the business layer and let your IoC container do the rest.
Create a separate assembly that contains the data containers. You can still let the business layer depend on the data layer, yet you don’t have to duplicate anything.
Use an ORM, like NHibernate.
If you ever created a project with just 2 parts, usually named ui/gui/presentation and core/logic/service, it’s actually the same. The only difference is that you implement the interfaces by which you retrieve your entities / business object, or however you want to call them, in a separate assembly. Done. Data stores of all kind can be implemented.
By doing so, you can unit test, without having to hit your real data store. Further, you can switch databases, just load a different data layer implementation and its done.
