n-tier C# applicaiton с методами BAL и DAL с точно такими же именами (подписи и т. Д.)

Question

Я нахожусь в проекте, в котором я не вижу смысла, как предыдущий разработчик принял решения.

1. же точные имена методов в DAL и БАЛ
2. Статика ВЕЗДЕ
3. что я должен делать с новыми методами следовать рекомендациям?

пример существующего кода:

Вызов Appliction (может быть консольного приложения или веб-приложение и т.д .. агностик)

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; 
     } 
    } 
} 

Да, все дело в том, чтобы иметь слои разделения, но когда используются одни и те же имена методов, и статические, и каждый просто делает то же точную вещь с переходом в строку и возвращает DataSet имеет «код запаха» для меня

Предложения по лучшим способам?

Answer 1

В соответствии со стандартным дизайном объектно-ориентированного программирования (ООП) ваши классы BAL должны представлять «вещи», которые имеют какое-то значение для реального мира. Вместо того, чтобы иметь CreditMgr, который имеет статический метод для получения CreditRqst, создайте класс CreditRequest, который хранит свои собственные данные (например, DataSet), и предпочтительно обертывает его каким-либо удобным для бизнеса способом (например, List of CreditLine или List of Account) ,

Оттуда вы можете либо реализовать метод Get внутри CreditRequest, либо вы можете включить CreditMgr в объект службы (например, «CreditBureau», «Bank», «AccountsDesk» и т. Д.), Который имеет метод который берет String GeoID и возвращает CreditRequest.

Кроме того, использование строк как ключей (например, в GeoID) также пахнет. Можете ли вы придумать что-то более строго типизированное? Вы можете создать класс GeoID, который будет выполнять требования (такие как максимальная длина, допустимые символы, требования к контрольной сумме и т. Д.)