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

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

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

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

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

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

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

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.

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

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

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

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

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