Создание объектов против SELECT непосредственно из базы данных

Question

В настоящее время я работаю над интеграционным проектом для подключения двух разрозненных систем.
Мой план состоит в том, чтобы настроить HTTP-API, чтобы система A выдавала команды через HTTP-POST в систему B.
Эти команды будут использоваться для выдачи команд CRUD базе данных SQL-сервера для извлечения и обновления данных членских карточек (например, «создать членство», «членство в обновлении» и т. д.), а затем вернуть данные в систему A как XML. Я знаю, Многозвенное дизайн диктует, что я должен иметь класс MembershipCard с несколькими свойствами:

public class MembershipCard 
{ 
    private string number; 
    private decimal points; 

    public string Number 
    { 
     get { return number; } 
     set { number = value; } 
    } 

    public decimal Points 
    { 
     get { return points; } 
     set { points = value; } 
    } 

Наряду с несколькими методами, которые делают вызовы к DAL:

public string GetPoints(string cardnumber) 
    { 
     return MembershipCardDB.BalanceRequest(cardnumber); 
    } 

Однако, у меня некоторые трудность оправдывает такой подход, как статический класс DAL, MembershipCardDB кажется выполнить всю работу, что мне нужно (если смотреть снизу):

public static string BalanceRequest(string cardNumber) 
    { 
     string response = string.Empty; 
     string sqlselect = 
      "SELECT Balance       " + 
      "FROM tbl_MemberShipCard    " + 
      "WHERE Card_No = @cardNumber     " + 
      "FOR XML PATH ('Card'), ROOT('CardBalance')"; 

     using (SqlConnection connect = new SqlConnection("Data Source=TEST\\TEST;Initial Catalog=TEST;User Id=sa;Password=TEST")) 
     { 
      connect.Open(); 
      using (SqlCommand command = new SqlCommand(sqlselect)) 
      { 
       command.Parameters.AddWithValue("@cardNumber", cardNumber); 
       response = (string)command.ExecuteScalar(); 
      } 
     } 
     return response; 
    } 

есть все, что я упускать из виду путем простого удаления класса MembershipCard и просто вытащить данные из базы данных и форматировать его как XML?

Answer 1

Дело в том, что вы должны иметь возможность писать свою логику программы независимо от любого интерфейса базы данных или XML-формата. Поместите всю базу данных в отдельный класс, который загружает и создает объекты. Делайте все, что вы хотите делать с объектами. Наконец, сохраните объекты обратно в базу данных или в xml. Однако, если ваш код касается только импорта и экспорта данных, вы можете отказаться от дополнительных классов.

Кстати, вы можете упростить MembershipCard класс, используя авто Реализуемый свойства:

public class MembershipCard 
{ 
    public string Number { get; set; } 
    public decimal Points { get; set; } 
} 

Я часто иметь статический DB класс

public static class DB 
{ 
    public static string GetBalanceRequest(string cardNumber) 
    { 
     ... 
    } 

    public static MembershipCard LoadMembershipCard(string cardNumber) 
    { 
     ... 
    } 

    public static List<MembershipCard> LoadMembershipCards() 
    { 
     ... 
    } 

    public static void SaveMembershipCard(MembershipCard membershipCard) 
    { 
     ... 
    } 
} 

Ваш MembershipCard класс может иметь метод

public string BalanceRequest() 
    { 
     return DB.GetBalanceRequest(this.Number); 
    } 

Lik e это у вас есть разделение операций с базой данных и другой логики приложения.

Answer 2

Если вы специально разоблачаете операции CRUD, может быть способ REST-интерфейса (см. Web API). С помощью этого маршрута, я считаю, вы были бы справедливы в использовании ваших классов базы данных напрямую. На самом деле это не является нарушением подхода N-уровня - веб-службы фактически служат интерфейсом к слою данных.

Вы даже можете сделать этот шаг дальше и выставить запрос с задержкой выполнения по вашей службе с помощью поддержки OData в текущих сборках.

Основная проблема заключается в том, что веб-API по-прежнему находится в стадии бета-тестирования и регулярно меняется. Поддержка OData, например, почти отсутствует в предварительном просмотре. Это намного более продвинуто в ночных сборках.

Answer 3

Многозвенное дизайн диктует, что я должен иметь класс MembershipCard с несколькими свойствами

Я не уверен, что это точно. Я думаю, что n-уровневый дизайн диктует, что каждый слой зависит только от слоев ниже него.И каждый слой не должен зависеть только от уровня ниже - вы можете пропустить уровни. Таким образом, ваш интерфейс веб-сервиса может пропустить доменный уровень и перейти непосредственно в репозиторий. Хотя даже тогда лучше всего добавить еще один слой между вызываемым, скажем, «Приложением», который дает вам пространство для добавления в дополнительную логику не-доступа к данным, а не для его утечки в ваш интерфейс/веб-службу.

«Console.ReadLine» в вашем классе доступа к БД смешивает пользовательский интерфейс с репозиторием, так что это явно не хорошо. Кроме того, использование статических методов затрудняет запись модульных тестов, что также не очень хорошо.

Отъезд ... Проект, управляемый доменом Эрика Эванса.

Answer 4

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

Иногда дизайн n-уровня может сэкономить ваше время позже, однако иногда количество дополнительного кода, которое вы должны написать сегодня, просто не стоит. Из того, что вы говорите, похоже, что вы уже вошли в последний лагерь.

Итак, вернувшись к моему первому заявлению, вы должны спросить себя: вы предвидите необходимость отделить форматирование данных (XML) от извлечения (SQL Query)?

Есть, конечно, случаи, когда вы можете. Например, XML очень многословный и содержит много лишних неинформативных данных, которые вы, возможно, не захотите в более позднее время. Связывая себя с тем, как SQL Server испускает XML, вы будете рассматривать переписывание, если вы решите пойти JSON.

Принимая это немного дальше, XML и даже JSON подходят для ограниченного количества данных, таких как несколько записей за раз, но если вы начнете передавать сразу сотни или тысячи, тогда количество данных может легко достигнуть точки, вы просто хотите отправить что-то похожее на файл CSV через провод. Опять же, вы столкнулись бы с переписыванием.

Однако, если вы построите его там, где вы можете просто подключить нового поставщика для обработки различных требований к форматированию, тогда вы должны написать новый код или заменить потенциально большие патчи старого кода ... Также было бы довольно легко поддерживает несколько форматов одновременно (XML, Json, CSV, Excel, ...), если форматирование не тесно связано с поиском.

Играя за адвоката дьявола, если мы говорим о небольшой системе, это может иметь значение, поскольку количество времени, затрачиваемого на переписывание кода из-за изменения формата, может быть тривиальным, и в этот момент я бы не потратил время на создание n-уровневая модель.

Надеюсь, что это поможет, в конечном счете, я не думаю, что мы сможем сказать вам, куда идти.