Я определил ниже уровни, которые будут реализованы в моем приложении. По моим знаниям многослойная архитектура предпочтительна для корпоративного приложения.
Я выбрал Symfony2 в качестве рамки, которая будет использоваться в приложении. В Symfony2 встроена архитектура MVC. И вышеупомянутые слои существуют, как показано ниже.
Модель состоит из уровня бизнес-уровня, уровня доступа к данным, уровня обслуживания. См. Изображение ниже, которое заимствовано из книги Мартина Фаулера « Шаблоны архитектуры корпоративных приложений» .
Моя проблема в том,
есть ли способ разделить модель на отдельный уровень бизнес-уровня, уровень доступа к данным, уровень обслуживания? Как реализовать многослойную архитектуру в PHP? Должен ли я использовать некоторые другие рамки (если только он поддерживает многоуровневую архитектуру)?
Ниже ссылки были полезны
Как следует структурировать модель в MVC?
Как создать n-многоуровневую веб-архитектуру с помощью PHP?
В чем отличие разработки веб-сайта в MVC и 3-уровневой или N-уровневой архитектуре?
MVC. Как подходит многоярусная архитектура?
Реализация уровня сервиса в архитектуре MVC
Достижение 3-уровневой архитектуры с помощью Symfony PHP
Если вы серьезно относитесь даже к созданию чего-то MVC-вдохновленного, то вашими единственными вариантами являются Synfony и Zend. Остальные – просто грустные Rails-клоны, которые реализуют некоторую утилизацию PAC . И Sf2.x кажется лучше одного из двух … но это похоже на то, что самый умный парень в классе исправлений.
Если вы не в состоянии и не хотите создавать свои собственные рамки, Sf2.x будет вашим лучшим выбором.
Я думаю, что главная проблема здесь заключается в непонимании того, что такое «модель» в MVC. Модель – это слой, а не какой-либо конкретный класс или объект. В картине из книги Фаулера « модель MVC » будет состоять из трех концентрических кругов.
У вас в основном есть два основных слоя в MVC: уровень модели и уровень представления. Уровень презентации взаимодействует с уровнем модели через сервисы, что позволяет абстрагироваться от бизнес-логики подкласса.
Не путайте его с « моделью домена ». Модель домена – это идея, которая описывает все знания и опыт бизнеса клиента, который используется при создании приложения. Обычно он будет представлен как отдельные объекты домена и взаимодействие указанных объектов.
Кроме того, эта картина несколько вводит в заблуждение. Уровень абстракции данных (обычно реализуемый как сборщик данных ) не является структурой нижнего уровня, а затем моделью домена. Оба объекта домена и абстракции хранилища используются службой (либо напрямую, либо через репозитории и единицы работы). Он называется «логикой приложения» и является прямой обязанностью служб.
Итог: нет, вам не нужно выбирать разные рамки. Вам нужно только узнать больше о архитектуре приложения. Вам следует прочитать « Шаблоны архитектуры корпоративных приложений» . Это было бы неплохо для начала.
Мои 2 цента