N-уровневая архитектура дизайн разделения проблем

Question

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

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

• UI
• Бизнес-объекты
• Логика / Бизнес
• DAL

UI должен вызывать только слой логики, чтобы получить его вещи

Business Objects не должен вызывать или иметь ссылки на что-либо еще, просто должен быть способ хранения данных

Слой Logic / BUSINESS должен содержать все методы для получения, создания, обновления, удаления (CRUD) объектов в системе и иметь ссылки как на BO, так и на BO. DAL. Он будет применять бизнес-логику к операциям, а затем делегировать фактический CRUD DAL.

DAL просто будет выполнять операции CRUD на БД. Он будет иметь ссылку на BO, поскольку он вернет их для Gets и т. Д.

Мой вопрос заключается в том, должны ли классы логики вызывать только свой эквивалентный класс DAL и вместо этого просто вызывать логические классы? Другими словами, класс CompanyLogic должен вызывать только класс CompanyDAL. Поэтому, если бы он хотел получить объект Client по идентификатору, он вызвал бы ClientLogic.GetClientByID(int), а не ClientDAL.GetClientByID(int).

Причина, по которой я подумал, что, возможно, должен остаться на собственном слое, заключалась в том, что:

1. Казалось бы, ослабить связь между проектами

2. Как насчет логики, если получение клиентского объекта имело некоторую логическую валидацию (возможно, не лучший пример, но надеюсь, что оно уловит смысл).

EDIT:

Я не уверен, что это плохой дизайн для меня, но на данный момент уровень BUSINESS имеет несколько классов, включая ClientBULL и CompnayBULL, оба класса имеют вызовы друг к другу. Я использую интерфейс для каждого класса и имею фабрику для создания объектов, чтобы попытаться уменьшить любые связи, но теперь они не могут существовать друг без друга из-за вызова методов в обоих классах. Это плохая идея?

Answer 1

Ну, вот мои комментарии к вашему дизайну:

• Логика - это плохое название для того, что по сути является слоем, назначенным на абстрактное постоянство. Я бы, вероятно, назвал бы это «Репозиторий» или «Постоянство» или DAO (объекты доступа к данным) вместо «Логика», что неоднозначно и может абсолютно означать что угодно .

• Если вы действительно хотите отделить свой бизнес-уровень от DAL, ваш уровень логики должен принимать только интерфейсы с DAL, а не конкретные классы DAL.

• Есть две школы мысли о том, где должна находиться валидация. Некоторые полностью согласны с проверкой на уровне пользовательского интерфейса; другие предпочитают генерировать исключения или передавать сообщения от бизнес-уровня. В любом случае, будьте последовательны, не дублируйте валидацию в нескольких местах, и все будет в порядке.

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

Гудлак!

Обновление

Повторное редактирование: внутри одного и того же пространства имен или сборки вызовы конкретных классов вполне подойдут. Я думаю, что вам будет слишком сложно создать интерфейсы для бизнес-логики. Я имею в виду, что вам нужно следовать более чем одному набору правил?

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