Если интересно развести холивар на тему, был бы очень рад побеседовать в личке (чтобы не засорять) и выяснить в чем отличия моей идеи и вашего HMVC.
Но по поводу «Можно.» готов спорить прямо здесь. Я очень часто сталкиваюсь с проблемой того, что приложение на MVC/HMVC имеет серьезные проблемы с архитектурой.
Если принять Модель за интерфейс работы с данными, то остается вопрос куда деть интерфейсы для работы с другими интерфейсами (Внешние API к примеру).
Я придерживаюсь правила, что не должно быть функционала больше чем требуется в данный момент. Это делает более трудоемким процесс расширения возможностей общей системы, но никак не сложнее. (OverEngineering — BAD!) Но каждый фреймворк предоставляет нам готовый интерфейс взаимодействия пользователя с данными (в нашем случае WEB), и даже более, что не всегда используется.
Как итог, реализация на Symfony (как фреймворк, он меня вполне устраивает) способов авторизации через соц. сети выливается в ручную установку пакетов, настройку, написания контроллера, функционала менеджера модели пользователя… проблема исчезнет, если функционал для работы с пользователем уже существует изначально в виде сервиса с возможностью к нему обратиться с другого сервиса или расширить существующий. В этом случае, как раз трейты нашего любимого PHP, а также фасадный патерн для сервисов очень кстати.
С уважением всех читающих CoreJournal. Жду ваших ответов.
Symfony от Sensiolabs я использовал в реальных проектах не один раз. Задача стоит не такая. Да и идея совсем не та. Symfony настоящий Framework on PHP. Но никак не готовая CMS. Я хочу написать «валидную» с точки зрения разработки и масштабируемости систему, которой сможет пользоваться даже дедушка.
Понимаете ли, взяв к примеру WordPress, DLE или прочие CMS, мы получим практически идеальную с точки зрения конечного пользователя (не отходящего за рамки возможностей) систему для администрирования блога или новостной ленты. Но также есть масса потребностей и спроса на хорошо поддерживаемую и понятную со всех сторон систему, которая предоставит удобный интерфейс как для пользователя так и для разработчика.
Работая в компании на протяжении последних нескольких лет, становится ясно чего хочет заказчик. Но увы, редко попадаются командные проекты чтобы начать писать что-то стоящее. И я не желаю тратить время на холивар о том, как много уже написано и «не пиши велосипеды». Все это уместно в конкретных ситуациях. Но если заказчик не из «нашего мира», и захочет магазин на WP, то и альтернатива для него в виде OpenCart к примеру, будет неуместна.
В данной ситуации, моя задача узнать какой максимально понятный програмный интерфейс для масштабируемости выбрать для своей CMS. Заметьте, что я ничего не пытаюсь вам навязать, продать или прорекламировать. Также вам не удастся отговорить меня воротить такими вещами и изобретать велосипеды. В каждом последующем посту, я буду выкладывать не однозначные задачи по решению конкретных архитектурных и программных вопросов.
Но по поводу «Можно.» готов спорить прямо здесь. Я очень часто сталкиваюсь с проблемой того, что приложение на MVC/HMVC имеет серьезные проблемы с архитектурой.
Если принять Модель за интерфейс работы с данными, то остается вопрос куда деть интерфейсы для работы с другими интерфейсами (Внешние API к примеру).
Я придерживаюсь правила, что не должно быть функционала больше чем требуется в данный момент. Это делает более трудоемким процесс расширения возможностей общей системы, но никак не сложнее. (OverEngineering — BAD!) Но каждый фреймворк предоставляет нам готовый интерфейс взаимодействия пользователя с данными (в нашем случае WEB), и даже более, что не всегда используется.
Как итог, реализация на Symfony (как фреймворк, он меня вполне устраивает) способов авторизации через соц. сети выливается в ручную установку пакетов, настройку, написания контроллера, функционала менеджера модели пользователя… проблема исчезнет, если функционал для работы с пользователем уже существует изначально в виде сервиса с возможностью к нему обратиться с другого сервиса или расширить существующий. В этом случае, как раз трейты нашего любимого PHP, а также фасадный патерн для сервисов очень кстати.
С уважением всех читающих CoreJournal. Жду ваших ответов.
Понимаете ли, взяв к примеру WordPress, DLE или прочие CMS, мы получим практически идеальную с точки зрения конечного пользователя (не отходящего за рамки возможностей) систему для администрирования блога или новостной ленты. Но также есть масса потребностей и спроса на хорошо поддерживаемую и понятную со всех сторон систему, которая предоставит удобный интерфейс как для пользователя так и для разработчика.
Работая в компании на протяжении последних нескольких лет, становится ясно чего хочет заказчик. Но увы, редко попадаются командные проекты чтобы начать писать что-то стоящее. И я не желаю тратить время на холивар о том, как много уже написано и «не пиши велосипеды». Все это уместно в конкретных ситуациях. Но если заказчик не из «нашего мира», и захочет магазин на WP, то и альтернатива для него в виде OpenCart к примеру, будет неуместна.
В данной ситуации, моя задача узнать какой максимально понятный програмный интерфейс для масштабируемости выбрать для своей CMS. Заметьте, что я ничего не пытаюсь вам навязать, продать или прорекламировать. Также вам не удастся отговорить меня воротить такими вещами и изобретать велосипеды. В каждом последующем посту, я буду выкладывать не однозначные задачи по решению конкретных архитектурных и программных вопросов.
З.Ы. Только за сотрудничество!)