Когда вы искажаете шаблон (не берете другой, а именно искажаете существующий) — вы усложняете работу тех, кто придет работать с кодом потом.
Не искажаем, а дополняем. Так как архитектура — это совокупность шаблонов.
Есть проблема — надо ее решить. Описать структуру Веб-приложения которая на практике НЕ ограничивается MVC паттерном. Я часто работаю с Веб-кодом разных людей и по итогу туда тулят Фабрики, Адаптеры и куча шаблонов которые только усложняют все и страдает бизнес, так как амбиции умников стоят немалых денег потом.
Кстати да, HMVC тут более подходит чем SOA. Почему то многие этот термин понимают исключительно как архитектура для больших проектов где явно видно разделение сервисов в отдельные приложения.
Тогда изменю немного текст и получится, что модели могут состоять из MVC связки. И тогда мы подключаем к контроллеру, как модель контроллер 2 уровня MVC. Который собирает в себе уже модели 2 уровня и View.
Windows отличается покупкой хороших решений. Например в Facebook они инвестировали довольно удачно. Последнее время они дружат с Linux и это даст им большое преимущество в будущем наверное.
«Что немаловажно — мы в любой момент можем заменить любую модель. К примеру, без особых проблем поставить более мощный генератор. Это — важно. Модели в MVC в идеале должны быть как запчасти автомобиля — иметь лишь интерфейс, своего рода API, что бы внедрение новой модели происходило максимально безболезненно для вашего кода.»
Да, в теории SOA касается в основном вынесением функциональности на внешние ресурсы. Но например PHP-код и MySQL внутри 1 сервера являются разными системами и общаются на языке SQL между собой.
Тут имеется ввиду не прямое сходство с SOA, а его принципы.
Если начинать создавать внутри такую структуру, то при расширении программы легко можно будет выносить например сложные вычисления на другие сервера без изменений в контроллерах с бизнес логикой.
Если использовать русское определение: Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.
То имеется в виду модульность и слабо связность на начальных стадиях, протоколы внутри дальше и вынесением в отдельные программы в будущем.
В простом случае сервис = обычный метод класса.
Когда программа растет куда-то нужно цеплять сложные системы и тогда в программе появляются сервисы.
И вместо простого метода получения из базы массива, появляется коммуникаторы по некоторым протоколам с внутренними сервисами или внешними. Смысл в том, что в контроллере это выглядет как подключение класса и запуск его метода подобно использованию модели в классической MVC структуре.
CI Users = Ion Auth
CI Admin (Everybody make himself) We have open-source solution: inside.ikiev.biz
CI Post (Everybody make himself) We have simple empty web-site: vizitka.ikiev.biz
CI Shop (Everybody make himself) We have simple empty web-site: shop.ikiev.biz
If anybody want to make it official and stable it will be good)
But main trouble is code quality. This Apps must be simple and easy to modify!
Вы считаете этот код легким и поддерживаемым?
По какой архитектуре вы программировали сайт?
Один из критериев — это кол-во абстрактных объектов которые НЕ относятся к бизнес-логике.
Чем меньше кол-во объектов используется что-бы решить ту или иную задачу тем код проще.
Именно на этом критерии и строится попытка создать описание структуры веб-приложения.
Как минимум той, которой вы оперируете.
Не искажаем, а дополняем. Так как архитектура — это совокупность шаблонов.
Есть проблема — надо ее решить. Описать структуру Веб-приложения которая на практике НЕ ограничивается MVC паттерном. Я часто работаю с Веб-кодом разных людей и по итогу туда тулят Фабрики, Адаптеры и куча шаблонов которые только усложняют все и страдает бизнес, так как амбиции умников стоят немалых денег потом.
Так как на практике можно называть что угодно как угодно, главное что бы сделано было в сроки и потом другие программисты могли работать с кодом.
А то много теоретиков на практике 5 дней делают то, что делается за 1. Зато на мега навороченных технологиях и согласно теории.
Тогда изменю немного текст и получится, что модели могут состоять из MVC связки. И тогда мы подключаем к контроллеру, как модель контроллер 2 уровня MVC. Который собирает в себе уже модели 2 уровня и View.
Важно наверное стандарты безопастности, а остальное уже на любителя.
«Что немаловажно — мы в любой момент можем заменить любую модель. К примеру, без особых проблем поставить более мощный генератор. Это — важно. Модели в MVC в идеале должны быть как запчасти автомобиля — иметь лишь интерфейс, своего рода API, что бы внедрение новой модели происходило максимально безболезненно для вашего кода.»
P.S. И уберите плз кто-то -1 в рейтинге… Я тут старался, писал) Пожалейте мою карму))
Тут имеется ввиду не прямое сходство с SOA, а его принципы.
Если начинать создавать внутри такую структуру, то при расширении программы легко можно будет выносить например сложные вычисления на другие сервера без изменений в контроллерах с бизнес логикой.
Если использовать русское определение: Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.
То имеется в виду модульность и слабо связность на начальных стадиях, протоколы внутри дальше и вынесением в отдельные программы в будущем.
Когда программа растет куда-то нужно цеплять сложные системы и тогда в программе появляются сервисы.
И вместо простого метода получения из базы массива, появляется коммуникаторы по некоторым протоколам с внутренними сервисами или внешними. Смысл в том, что в контроллере это выглядет как подключение класса и запуск его метода подобно использованию модели в классической MVC структуре.
CI Users = Ion Auth
CI Admin (Everybody make himself) We have open-source solution: inside.ikiev.biz
CI Post (Everybody make himself) We have simple empty web-site: vizitka.ikiev.biz
CI Shop (Everybody make himself) We have simple empty web-site: shop.ikiev.biz
If anybody want to make it official and stable it will be good)
But main trouble is code quality. This Apps must be simple and easy to modify!
Предложение автору: оставь свои контакты, может PM-ом возьмут сразу в один из проектов. Мышление правильное =)
Если есть альтруисты, предлагаю поделиться с хабраюзерами)
Итого:
Безопасный AJAX:
1) HTTP_REFERER
2) token
3) Защита от роботов
Верно?
Мой критерий выбора языка программирования — это количество успешных и привлекательных (для меня) проектов реализованных на нем.