немножко о логике

Здравствуйте, поговорим немножко о логике.
В общем, читаю одну занятную книгу "Совершенный код", думаю многие с ней знакомы. Для тех, кто не знаком, я немного опишу ситуацию, которая вызывает достаточно спорную точку зрения и хотелось бы, чтобы более опытные люди написали свою точку и так..
Идеология автора - сделать класс гибким и высококачественным.Не буду переписывать книгу, скажу в 2 словах, класс должен быть черной коробкой отвечающий логическим требованиям.
Я понимаю это так - есть контроллер Авторизации, он включает в себя методы по регистрации и авторизации пользователей очищать значения и ждать результата от модели.Мне вполне нравится идея взводить класс в объект реального мира,но недавно начал работать с Фреймворками и заметил, что разработчики некоторых Фреймворков склоняют использовать виджеты,что производит противоположность в логике.Тут весьма авторитетный автор,а с другой стороны много разработчиков и создателей данных Фреймворков.
Расхождение заключается в том, что мы перекладываем логику контроллера на очень узкопрофильный виджет и делаем контроллер просто юзабилити данных виджетов и моделей.Контроллер становится действительно еще более тоньше и гибче,но задача виджета становится настолько узкой, что мы теряем понятия одной коробки с инструментами.Автор книги "Совершенный код" говорит - у вас есть машина, а в ней будут методы ее управления.В данной же концепции у нас есть корпус машины в который мы пихаем детали.
Вопрос к опытным разработчикам, какой концепции стоит придерживаться при условии написания проектов с использованием MVC в приделах интернет разработки??
Спасибо.

Как считаете нужным — так и делайте, в процессе разработки сами придете к лучшему варианту.

моя личная концепция - держатся подальше от MVC

впрочем не вижу никаких "противоположностей в логике" виджетов ни с MVC ни тем что написано у Макконнела или как его там.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

логика MVC естественно остается не тронутой ) но а на счет что написано у Макконола по моему весьма разная точка зрения Макконоло предлагает делать узко направленные черные коробки с функционалом для одного объекта виджеты же делят этот функционал на очень узкие части заставляя так называемаю коробку зависеть и переносить логику в нее.

А в чем тут расхождение? Раньше у тебя было 3 коробки (модель, контроллер, вьюха), которые по строго заданным интерфейсам взаимодействовали. Введя виджет, ты добавил черных коробок и интерфейсов их взаимодействия, не более
(Добавление)
Ну хотя бы потому что иногда требуется писать быстрый код
Если переносить аналогию в реальный мир, вы предлагаете писать класс "машина", у которой будет интерфейс "вперед, назад, поворот, тормоз, заправить" и тд Виджеты - это уровень запчастей "тормоза, рулевая, подвеска" Если смотреть еще ниже - вы увидите классы фреймворков для работы с сессиями, кэшами, базами и тд - это уже уровень "гидравлический цилиндр передних дисковых тормозов" ... если заглянуть в конкретные адаптеры фреймворков - вы увидите винты, болты и гайки ... речь лишь о разном уровне детализации

Парни MVC есть MVC. Model отвечает за бизнес логику. View за представление. Controller Контролирует. Они не могут быть универсальны. Так как реализуют бизнес логику Сайта.
А вот Этакие черные боксы про которые вы говорите являются компонентами - на самом деле в основном это просто классы отвечающие за определенные действия Например Класс работы с сетью или класс работы с файлами класс работы с бд это то что можно использовать как инструменты MVC это фундамент , компоненты это инструменты(гаичный ключ пила дрель итд), бизнес логика - материалы(доски,окна,двери с уже готовым чертежем) в итоге будет построен Дом(Сайт).

alexxorlovv, если честно, я не смог сделать выводы из того, что ты написал ... выделить суть послания. "Model отвечает за бизнес логику. View за представление. Controller Контролирует." Бизнес-логика не может быть зашита только в модели, по крайней мере я такого ни разу не видел. Логика валидации не в модели, логика логирования, распределения прав доступа и тд - это тоже бизнес-логика, но она не в моделях. Касательно контроллера все еще менее понятно, что он контролирует? Да и с вьюхами все не так гладко, современные фреймворки и cms-системы дают возможность подгрузки вложенных шабллонов, использования хэлперов и отложенной простановки переменных, что, по факту, является переносом части логики в эти самые вьюхи

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

я тоже. Банальные фразы ниачем. Как и в остальных его сегодняшних постах.


по класике - именно там.


не совсем бизнес-логика. Скорее это логика контроллера.
бизнес-логика редназначена для работы с бизнес-данными. Потому и должна быть в модели

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



это логика построени страницы а не бизнес-логика. Страниц модет вообще не быть (например идет работа через веб сервисы или какое другое API) а бизнес логика должна остатся (еще одна причина расположения бизнеслогики в модели).



да, только как ты сам заметил, большая проблема - распределить что в каком яшике должно быть. MVC паттерн клево смотрится только на картинке в википедии.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Ну это же обман самого себя Я последние года 4 работаю исключительно с e-commerce, поэтому и говорю, восновном, на их примерах, так вот тут невозможно бизнес-логику вшить исключительно в модели. Куча логики наворочена в расчетах доставок, наличий, цен, куча логики зашита в маршрутах синхронизаций данных, куча логики зашита в обработке ошибок, ретраях, вся логика сильно вариативна - невозможно это все поместить на уровень моделей

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

возможно
если не понимать под моделью то что обычно понимают под entity - класс сущности


на счетчтки влияют действия пользователя а не логика построения страницы. Прочуствуй разницу

Ближе к теме кагбэ то как должно быть а не у кого с какой степентю кривости реализовано.

Хотя в MVC не криво написать - вообше проблематично.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Есть счетчики, регистрирующие действия пользователя (клики, наведения и тд), есть счетчики, регистрирующие показы (товар показан в блоке рекомендуемых, товар показан в листинге, услуга предложена с товаром таким-то и тд), на них действия пользователя не влияют

а кому они тогда показываются?

открытие определенной страницы и есть действие пользователя.
и модель может регистрировать эти показы прямо в момент запроса того или иного товара.

доп. параметры которые возможно нужны для статистики: типа id пользователя или его IP как правило есть в сессии и модель запросто может это считать и зафиксировать - юзеру такому то показаны такие то товары

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore