Архитектура с тремя уровнями

Question

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

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

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

---

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

Answer 1

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

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

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

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

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

Answer 2

Это зависит от многих факторов. Я бы посмотрел на использование шаблона repositiry для вашего уровня доступа к данным (DAL). В идеале это будет использоваться в сочетании с объектным реляционным mapper (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

Answer 3

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

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

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

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

Answer 4

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

2. Любой уровень должен знать только об уровне ниже его. Напр. Пользовательский интерфейс должен взаимодействовать только с Business Logic и не должен знать ничего о слое данных. Для этого всегда code to interfaces instead of concrete implementations. Используйте Dependency Injection, чтобы модули были слабо связаны.

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

Answer 5

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

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

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

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

Answer 6

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

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

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