BLL, DAL, OBJ и трехслойная архитектура

Question

Мой вопрос о трехслойной архитектуре.

Мой проект вкратце похож на ниже, однако то, что меня раздражало после того, как я вставляю новый столбец в свою базу данных, мне нужно обновить все поля, кроме BLL. В слое представления я создал OBJ, а также внутри DAL plus внутри DAL, есть SQL-запрос. Я должен обновить все эти поля вручную.

Если я делаю это «обычный» способ, я помещаю все это внутри слоя презентации и обновляю все в одном месте.

Я применяю эту трехслойную архитектуру правильно и в чем преимущества использования этой многоуровневой архитектуры?

Мой второй вопрос:

Внутри DAL, я собираю данные через _view. Что мне интересно, должен ли я писать еще один BOboj для каждого представления? У меня уже есть класс BOboj, но он не содержит всех полей.

При вставке данных я должен использовать мой BOboj, однако при перечислении данных я использую представления, в этом случае должен ли я создать другой класс BOboj_view для каждого вида или другого? Каков способ облегчения этого?

например; У меня есть 20 видов и 40 классов, которые сопоставлены с каждой таблицей на сервере sql. Мои представления собирают таблицы данных с разными значениями (это означает разные объекты). Должен ли я создать еще 20 классов, кроме 40, которые представляют представление?

OBJ

class BOboj { 
     private int _PId; 
     private string _Name; 
     ....... 
     ....... 


} 

ДАЛ

BOboj_DAL { 

     public bool Add(BOboj obj) 
     { 
      using (SqlConnection con = Connect.connect) 
      { 
       string sql = "insert into Persons (Id,Name, 
       ....... 
       ....... 
} 

BBL

BOboj_BLL { 

     ....... 
     ....... 
     public bool Add(BOboj_DAL obj) 
     { 
      BOboj_DAL bb_dal = new BOboj_DAL(); 
      try 
      { 
       return bb_dal.Ekle(obj); 

      } 
      catch (Exception) 
      { 

       throw; 
      } 
      finally { bb_dal = null; } 

     } 

     ....... 
     ....... 
} 

Presantaon Слой

protected void Add(object sender, DirectEventArgs e) 
     { 
      BOboj_BLL bll_= new BOboj_BLL(); 

      BOboj obj_ = new BOboj 
      { 
       Name = Name.Text, 
       .............. 
       ............... 

      }; 
      bll_.Add(obj_); 
} 

Спасибо.

Answer 1

С MSDN статьи -

Основные преимущества N-уровневой/3-уровневой архитектурного стиля:

• ремонтопригодность. Поскольку каждый уровень не зависит от других уровней, обновления или изменения могут быть выполнены без ущерба для приложения в целом.
• Масштабируемость. Поскольку уровни основаны на развертывании слоев, масштабирование приложения достаточно просто.
• Гибкость. Поскольку каждый уровень можно управлять или масштабировать независимо, гибкость увеличивается.
• Доступность. Приложения могут использовать модульную архитектуру позволяющих систем с использованием легко масштабируемых компонентов, что увеличивает доступность .

У вас плотно соединенные слои. Попытайтесь сделать их свободными.

Для начала, после шаблона решения Visual Studio может помочь вам -

Layered Architecture Solution Guidance 2010

Answer 2

1. DA Объекты должны представлять схему базы данных какой-либо образом и должны быть строго переплетены с деятельностью базы данных.

2. Бизнес-уровень - это место, где вы должны манипулировать данными с использованием конкретной логики проекта. Ваш бизнес-объект не всегда совпадает с объектом DA (представьте себе объект DA с двумя свойствами Forename и Surname, но по некоторым причинам ваш объект BO имеет только одно свойство Surname, поскольку Forename никогда не используется в логике. Когда бизнес меняет свое мнение и они тоже хотят манипулировать с именем Forename, вы должны добавить его только в этот слой).

3. Объекты уровня презентации должны быть строго привязаны к представлениям. Логики не должно быть. Эти объекты должны использоваться только для отображения действий.

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

Также помните, что в некоторых случаях, например, в проектах, которые используют веб-службы, может быть реализован четвертый уровень с сервис-ориентированными объектами.