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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Более подробная информация — https://www.c-sharpcorner.com/UploadFile/dacca2/understand-3-tier-architecture-in-C-Sharp-net/