Трехуровневая архитектура

Question

У меня есть несколько вопросов о трехуровневой архитектуре.

1. как правильно реализовать приложение в трехуровневой архитектуре?
2. как обмениваться данными между этими уровнями?
3. Является ли уровень данных полностью равным СУБД?(как в случае, если мы используем хранимые процедуры, и как в случае, если мы использовали инфраструктуру реляционного отображения объектов?)

с нетерпением ждем ваших ответов.Спасибо.

---

PS: Пожалуйста, не понимайте, что я задаю общий вопрос.ОК ?Я спрашиваю, как правильно разработать крупномасштабное приложение.Какой ЛУЧШИЙ путь?Не ожидая слишком много ответов.

Answer 1

Это широкие ответы, я сделаю все возможное, чтобы дать вам несколько советов.

1. «Правильно» - это несколько субъективный термин. Вообще говоря, на мой взгляд, самое важное - это сохранить слой в своем собственном модуле (например, в своей собственной DLL) и иметь интерфейсы, входящие и выходящие из модуля. Используя интерфейсы на каждом уровне, вы можете отделить определение от реализации, дополнительно отделив слои друг от друга. Если в слое есть одна точка входа, и она основана на интерфейсе, при необходимости вы можете иметь несколько базовых реализаций. В другом направлении, если вы используете интерфейсы в качестве обратных вызовов, клиентам уровня (то есть другим уровням) нужно будет только реализовать интерфейсы, чтобы получить хороший поток между уровнями.

2. Это зависит от того, как вы реализуете сами слои. Если вы создаете слои, как я предлагал выше, вы просто используете интерфейсы, чтобы войти в слой и выйти из него. Другое решение может заключаться в том, чтобы сделать его асинхронным с использованием диспетчера событий - слой просто запустит событие, а другой слой будет прослушивать это событие и воздействовать на него. Все зависит от конкретных требований проекта.

3. Нет, уровень данных - это уровень в приложении, взаимодействующий с СУБД. Использование ORM - это просто метод для реализации уровня данных, в то время как использование хранимых процедур - это метод для перемещения некоторой логики из приложения в саму СУБД по разным причинам.

Полагаю, вы получите несколько ответов; Вы должны принять их во внимание, почитать в сети и немного поэкспериментировать, пока не найдете то, что вам нравится.

Answer 2

Эта тема слишком широка, чтобы правильно ответить на этот вопрос с необходимой глубиной.Тем не менее:

1. Ключевым элементом является правильное ограничение зависимостей между слоями, чтобы каждый слой знал только о слое «ниже».например, бизнес-уровень не знает о уровне представления.

2. 3-уровневая архитектура не предписывает, как слои взаимодействуют между собой.Бизнес (уровень) функциональность часто представлена ​​в виде веб-сервисов, которые используются на уровне представления.

3. Уровень данных не полностью равен базе данных.Вам всегда понадобится некоторый код для взаимодействия с хранилищем данных (например, ORM).Этот код должен быть в своем собственном модуле, чтобы минимизировать связь.

Answer 3

1. Три уровня: презентация, бизнес-логика и данные.Убедитесь, что вы не смешиваете проблемы.Пользовательский интерфейс не должен содержать бизнес-логики и т. Д.

2. Любой уровень должен знать только об уровне ниже его.НапримерПользовательский интерфейс должен взаимодействовать только с Business Logic и не должен ничего знать о уровне данных.Чтобы достичь этого, всегда кодируйте интерфейсы вместо конкретных реализаций .Используйте Внедрение зависимостей для слабой связи модулей.

3. Это зависит от того, как вы решите его реализовать.Начните с ЯГНИ принципал.Начните с максимально простых вещей и используйте такие вещи, как ORM, только если они действительно вам нужны.

Answer 4

В трехуровневой архитектуре есть три уровня: уровень представления, уровень бизнес-логики и уровень доступа к данным. Помимо этих трех, мы можем использовать слой бизнес-объектов для реализации классов свойств, которые могут отображать наши объекты в базе данных, или вы можете использовать платформу сущностей.

Презентационный слой: Это самый верхний уровень приложения, где пользователь выполняет свою деятельность. Давайте рассмотрим пример любого приложения, в котором пользователь должен заполнить форму. Эта форма - не что иное, как Уровень представления. В приложениях Windows Windows Forms являются слоем представления, а в веб-приложениях веб-форма принадлежит слою представления. По сути, на этом уровне выполняется проверка ввода пользователя и обработка правил.

Бизнес-уровень: Это поверх уровня презентации. Как следует из названия, большинство бизнес-операций выполняются здесь. Например, после сбора данных формы мы хотим проверить их с помощью нашего пользовательского бизнес-правила. В основном мы определяем классы и бизнес-объекты в этом слое.

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

Дополнительная информация - https://www.c -sharpcorner.com / UploadFile / dacca2 / понимаю-3-уровня архитектуры в C-Sharp-net /

Answer 5

Лучший способ реализовать приложение в трехуровневой архитектуре - это использовать среду вашего языка, которая использует MVC. Для PHP я рекомендую CodeIgniter http://codeigniter.com/

Обычно происходит прохождение объектов, если вы следуете ООП, между тремя уровнями. Ну, в основном два. Элемент управления получает запрос, запрашивает модель (БД) и получает взамен объект, использует его свойства и методы для отображения представления.

Следуйте некоторым учебникам в Ci. Вы получите представление о том, что происходит в MVC.

Answer 6

Трехуровневая архитектура - это концепция, а не пошаговая инструкция. Держите это простым и изолированным. Если вы работаете с хранением и поиском данных, поместите их в слой данных. Когда есть логика, которую нужно иметь, поместите ее в логику / средний уровень. Темы / обложки, представления, заполнители виджетов помещаются в слой представления.

Изучите чужой код. Хорошее место для начала было бы monoRail .

Читайте много документации, чем больше вы знаете, что делают другие, тем лучше.

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

Answer 7

Это зависит от многих факторов. Я хотел бы взглянуть на использование шаблона репозитария для вашего уровня доступа к данным (DAL). В идеале это должно использоваться в сочетании с объектно-реляционным картографом (ORM), например, структурой сущностей 4 или nhibernate. Тогда у меня будет отдельный доменный слой, содержащий бизнес-правила и сервисы. Ваш уровень домена будет обслуживать запросы между вашим пользовательским интерфейсом и вами DAL. Для вашего пользовательского интерфейса у вас есть возможность веб-форм или подход MVC. Оба будут работать на трех уровнях, но вы получите гораздо лучшее разделение проблем от MVC. Это хорошо, когда вы хотите провести какое-то модульное тестирование. Вот несколько хороших ссылок относительно вышеупомянутого.

http://daveswersky.com/2010/05/26/entity-framework-4-then-and-now/

http://channel9.msdn.com/blogs/matthijs/aspnet-mvc-2-basics-introduction-by-scott-hanselman

http://www.asp.net/mvc/tutorials/mvc-music-store-part-1