GUI, BLL, DAL Организация в проекте

9

Я читаю о слоях приложений и хочу использовать этот дизайн в моем следующем проекте (c #, .Net). Некоторые вопросы:

  1. Делается ли разделение слоев через пространства имен? Project.BLL. Что бы то ни было, Project.DAL. Что бы то ни было

  2. Более уместно разделить по слоям, а затем по компонентам (Project.BLL.Component1) или по компонентам, а затем по слоям (Project.Component1.BLL)

  3. Для моего DAL, этот слой далее организован, используя различные классы? Если все вызовы базы данных помещены в один класс, организации не существует. Было бы лучше разделить их на разные классы или пространства имен?

  4. Классы DAL обычно статичны? Кажется обременительным создавать экземпляр объекта DAL перед каждым вызовом одного из его методов.

Любые другие советы для правильной работы с этими слоями приветствуются.

sooprise
источник

Ответы:

8
  1. Да. А также сборки.
  2. Я бы разделил по слоям, потом по компонентам.
  3. Да. Есть разные подходы к этому, но у меня есть IDatabaseService (абстрагируясь от различных способов вызова базы данных - это может быть почти прямое отображение ExecuteScalar / ExecuteNonQuery / ExecuteReader), а затем различные классы доступа к данным, которые разделить по типу данных. Например, у вас может быть класс UserDataAccess, который будет иметь простые методы CRUD, которые создают / изменяют / удаляют объекты User. Другой подход заключается в том, чтобы иметь объект User, в который встроен CRUD.
  4. Нет . Это делает его гораздо сложнее для модульного тестирования. Вы должны использовать внедрение зависимостей, чтобы передавать зависимости конструктору каждого класса доступа к данным (например, IDatabaseService). Затем вы должны передать объекты доступа к данным в бизнес-объекты, например так:

    BusinessObject businessObject = new BusinessObject (new DataAccessObject (new DatabaseService ())); businessObject.PerformOperation ();

Каждому бизнес-объекту может потребоваться несколько объектов доступа к данным. Ваш код GUI также будет использовать один или несколько бизнес-объектов. Некоторые бизнес-объекты могут не нуждаться в каких-либо объектах доступа к данным, но никогда не должны напрямую использовать IDatabaseService.

Мэтью Родатус
источник
Таким образом, businessObject.PerformOperation () будет выглядеть примерно так: DataAccessObject.PerformOperation (), поскольку экземпляр DataAccessObject живет в businessObject?
sooprise
1
Также спасибо за подсказку о внедрении зависимостей. Это новая концепция для меня, и она, кажется, имеет смысл. Я должен буду узнать больше об этом :)
sooprise
@sooprise Right - ваши бизнес-объекты должны работать с объектами доступа к данным, которые являются частными участниками. Рад, что вы цените совет о внедрении зависимости. Это важная концепция для поддерживаемого и проверяемого дизайна программного обеспечения. Добро пожаловать!
Мэтью Родат
2

На вопросы 1 и 2 ответьте с ответами Мэтью.

Я потратил много времени, пытаясь найти лучший способ структурировать DAL настольных приложений. И лучший способ действительно зависит от потребностей приложения. В одном из моих приложений я пошел по пути создания класса DA для каждой таблицы базы данных, который регистрировался с помощью центрального (то есть одноэлементного) класса DataProvider и обрабатывал CRUD. Каждый класс DA мог бы затем решить, хочет ли он кэшировать все данные таблицы в ОЗУ или нет (производительность!) И / или должен ли он иметь возможность запускать автоматические обновления клиентов на других клиентах, работающих на других компьютерах (например, многопользовательский) параллелизм). Это позволяет легко добавлять новые классы DAL, поскольку все, что им нужно сделать, это соответствовать интерфейсу регистрации.

Не каждому DAL требуется такая функциональность, но я узнал, что сам подход (т. Е. Поставщик одноэлементных данных и простые классы DAL со статической регистрацией) значительно облегчил мою жизнь, когда я начал добавлять новые классы.

Я определенно не рекомендовал бы встраивать CRUD в классы более высокого уровня, если только это не очень простое приложение. DAL - это абстракция хранилища данных. Если вы решите изменить свое хранилище данных в будущем (даже если будет использоваться только MySQL вместо MS SQL), вы будете очень благодарны за это. Плюс: объекты BLL должны быть структурированы по их отношениям бизнес-логики. Объекты DAL структурированы по типам контейнеров хранения, которые они представляют. Различия могут быть драматичными.

Как НЕ сделать ваши классы DAL статическим. То, что вы получаете в скорости кодирования, вы многократно потеряете в тестируемости и гибкости.

wolfgangsz
источник
Вы правы в том, что конкретный дизайн определяется потребностями приложения. Однако, если я не пойму вас неправильно, я не согласен с использованием синглетонов. Может быть, вы могли бы объяснить свой подход больше. Почему синглтоны являются злом: blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
Мэтью Родатус
Извините, но я не согласен с одиночками. Есть очень веские причины для их использования, и все вещи, упомянутые в этом блоге, звучат как оправдание тому, кто не хочет применять необходимую дисциплину к своему кодированию.
wolfgangsz
Подробное объяснение моего подхода заполнило бы намного больше, чем то, что я могу предоставить здесь в комментариях. Отправьте мне свой адрес электронной почты, и я отвечу (wolfgangs на manticoreit dot com)
wolfgangsz