I'm currently finding myself in an application that must have been a bear to maintain. One of the things the prior programmer (PP) did right (IMHO) is split out the code into multiple layers including the "must have" Business and Data layers. The issue I have is that the PP did not fully understand object oriented programming (even though they used Interfaces galore [something I have really yet to do]).
Here is a method in the business layer:
public int ApproveDocument(int documentID, int toFromID,DateTime approvedDate, int docTypeDocEventsID, int sessionID)
{
return this.DocEvent.ApproveDocument(documentID,toFromID,approvedDate, docTypeDocEventsID,sessionID, null);
}
Over in the Data layer we have:
public int ApproveDocument(int documentID, int toFromID, DateTime approvedDate,
int docTypeDocEventsID, int sessionID, SqlTransaction tx)
{
... lotsa code
}
The problem is, these are the same methods, and it is being unessesary duplicated. This one class alone has 25 other duplicate methods. Multiply that by 100 or so classes in the Business Layer and we're talking roughly 2,500 unessesary methods. Wow! I hate the data layer with a passion. Could you imagine having to duplicate your comments across layers, and geez, what happens if a table changes and you need to update your methods? Peeee-uke.
The solution is simple. The Data Access layer classes should have been marked with a abstract keyword. This way the Business Layer class can just inherit them. Now you can call the Data Access layer through the Business Layer while eliminating the need for the duplicate method.