N-Tier Application Design

Question

Я довольно новичок в архитектурных проектах в ООП (я исхожу из программирования робототехники, так что это битва). Команда, в которой я участвую, создает довольно большое приложение, и ведущий руководитель проекта представил нам требования и в этих требованиях мы должны использовать Layers при создании модулей. Технологии, которые мы используем, - это C# WinForms и Oracle для хранилища данных.

Мой модуль состоит из Администрации пользователя и я попытался отделить логику от реализации, поэтому у меня есть следующая АРХИТЕКТУРА:

• Business Layer
• Уровень данные
• Presentation Layer

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

_userRepo.InsertNewUser(new User { props here }); . 

Так что это неверно, потому что доступ к DAL непосредственно. Мой босс сказал мне, что мне нужен еще один слой, который изолирует эти вызовы и реализует бизнес-правила (?!)

Я искал и исследовал Интернет, и я не нашел ничего полезного (в основном потому, что все отфильтровано здесь на работе).

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

Любая помощь будет оценена по достоинству.

Answer 1

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

фундаментально, я думаю, что ваш босс хочет, чтобы уменьшить зависимостей между всеми слоями. Архитектурный шаблон, который вы выберете для этого, зависит от приложения. То, что вы описали, выглядит как three-tier architecture. Давайте кратко вспомним, как выглядит трехуровневая архитектура и как должны работать вещи:

• Уровень презентации отображает информацию и служит границей для пользователя.
• Уровень приложения (или бизнес-логика) управляет функциональностью приложения. В частности, он обрабатывает данные и распространяет их на другие уровни.
• Уровень данных, содержащий уровень доступа к данным (DAL), сохраняет или извлекает данные. Он должен поддерживать ваше приложение независимо от решения для хранения данных. Он обычно работает с объектами доступа к данным (DAO).

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

A. Дисплей существующего пользователя

1. Бизнес-логика задает уровень данных для конкретного User DAO, например, тот, который соответствует id==123.
2. Уровень данных возвращает объект User.
3. Бизнес-логика считывает значения, хранящиеся в объекте User, и соответственно устанавливает значения в уровне представления, например. firstName, lastName и т. д. Он не пересылает непосредственно User, только содержащиеся значения.

B. Создание нового пользователя

1. Презентация уровня собирает все значения, необходимые для создания нового пользователя.
2. При отправке эти значения поступают в бизнес-логику (например, IoC).
3. Бизнес-логика сообщает уровню данных, чтобы создать новый объект User со значениями, полученными от уровня представления.
4. Уровень данных создает и сохраняет объект.

Что создает зависимости между различными уровнями являются DAO. То есть если ваш уровень представления должен был создать объект User, ему нужно будет импортировать класс, принадлежащий DAL (это не то, чего хочет ваш босс). Итак, что вы можете сделать, это оставить всю связь между уровнем представления и уровнем данных в бизнес-логике.

В качестве альтернативы в сценарии B вы также можете создать бизнес-логику для создания User, чтобы ваши методы DAL упростились.

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

Answer 2

Благодарим вас за все ответы и рекомендации.

Я думаю, что мой босс хочет (я не мог дотянуться до него, потому что он в DE, и я в RO) - полностью отделить проблемы между слоями, что-то вроде шаблона Model-View-Presentation, поэтому что уровень представления (UI) не будет напрямую обращаться к слою данных. Он может получить доступ к нему, но через промежуточный слой.

Я добавил в приложение уровень «Домен/Сервис», и теперь уровень представления вызывает уровень обслуживания, а уровень обслуживания вызывает «Бизнес-уровень» и создает объекты пользователя/группы.

Следующее, что он сказал что-то о бизнес-правилах, которые должен включать этот слой домена. Каковы эти бизнес-правила, пример будет оценен?

Единственное, что я придумал для бизнес-правил, - это некоторые Правила валидации, такие как: Перед вызовом: return userRepository.GetUserName (Пользователь пользователя) проверяет объект пользователя, переданный как параметр, который не является нулевым или аналогичным проверкам.

Так что теперь «механика» являются:

В Presentation Layer I вводят в конструктор объекта IService, а затем я использовать объект IService для вызова метода например, «GetAllUsers()».

IService per-se на самом деле является «копией» класса репозитория объекта пользователя, поэтому, когда объект IService вызывает «GetAllUsers()», в классах IService будет указан точный именованный метод: «return _userRepository.GetAllUsers() "- таким образом слой презентации вызывает специфические для объекта методы через посреднический слой, и этот промежуточный уровень будет иметь прямой доступ к определенным методам DL.

Надеюсь, я сделал себя как можно яснее. При необходимости я предоставит скриншоты.

Как я уже говорил, я просто beggining иметь опыт работы с АРХИТЕКТУРА дизайна, так как в роботизированных полях нет такой вещи, поэтому, пожалуйста, не бросайте так много пород: D