n-tier c# applicaiton with BAL and DAL methods with exact same names ( signatures etc.. )

Question

I'm on a project in which I'm failing to see the point of how a previous developer made decisions.

1. same exact method names in DAL and BAL
2. static is EVERYWHERE
3. what should i do with New methods to follow best practices?

example of existing code:

Calling appliction (could be console app or web app etc.. agnostic )

DataSet DS = CreditMgr.GetCreditRqstInfo(ddlGEO.Text);

BAL

public class CreditMgr
{
   public static DataSet GetCreditRqstInfo(String GeoID)
    {
        try
        {
            DataSet DS = new DataSet();
            DS = CreditIntfDB.GetCreditRqstInfo(GeoID);
            return DS;
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
}

DAL

public class CreditIntfDB
{
     public static DataSet GetCreditRqstInfo(String GeoID)
    {
        try
        {
            Database DB = new SqlDatabase(Common.ConnectionString);
            String SQLCommand = Common.SPGetRqstInfo;
            DbCommand DBCommand = DB.GetStoredProcCommand(SQLCommand);
            DBCommand.CommandTimeout = Common.CommandTimeOut;
            DB.AddInParameter(DBCommand, "@a_geo_id", DbType.String, GeoID);
            DataSet DS = new DataSet();
            DB.LoadDataSet(DBCommand, DS, new String[] { "CreditRqstInfo" });

            return DS;
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
}

Yes, the whole point is to have layers of separation, but when the same method names are being used , and static, and each are simply doing the same exact thing with passing in string and returning a DataSet has "code smell" to me

Suggestions on better ways?

Answer 1

According to standard Object-Oriented Programming (OOP) design, your BAL classes should represent "things" that have some real world business meaning. Instead of having a CreditMgr that has a static method to get a CreditRqst, create a class CreditRequest that stores its own data (e.g. the DataSet), and preferably wraps it in some business-friendly manner (e.g. List of CreditLine or List of Account).

From there, you can either implement the Get method inside of CreditRequest, or you can turn CreditMgr into a service object (such as "CreditBureau", "Bank", "AccountsDesk", etc.), that has a method that takes a String GeoID and returns a CreditRequest.

In addition, using strings as keys (e.g. in GeoID) is smelly as well. Can you come up with something a little more strongly typed? You could create a class GeoID that enforces requirements (such as maximum length, allowable characters, checksum requirements, etc.)