Как лучше разбить логику?

имеет. Маленькими вещами проще управлять.

хотя потом всеравно геттеров и сеттеров наплодят... смысл тогда ООП загоняться.

контроллер не должен содержать логику приложения. Это если вас интересует "как правильно". Он содержит точки входа для UI (Http как правило), то есть тупо конвертирует http запрос в вызов метода какого-то объекта (не будем называть это моделью для упрощения), и формирует http ответ на основе каких-то данных (которые тоже запрашивает у какого-то объекта а не лезет сам)

классы мэнеджеры - это прямое нарушение SRP и запах процедурного программирования. Когда вы видите класс "UserManager" вы можете точно передать чем он занимается? Ну да, менеджит юзеров, а что это означает? И вы начинаете перечислять обязанности.

Суть ООП сводится к тому, что у вас есть объекты, хранящие состояние, и они могут только обмениваться сообщениями. Причем чем меньше аргументов - тем лучше.

Как упражнение - попробуйте предложить мне как сделать оформление заказа без единого класса менеджера, сеттеров, геттеров и прочего булшита? У вас есть только классы User, Product, Order и возможно OrderLine, который должен хранить некоторую информацию о продукте (хотя бы стоимость на момент оформления заказа) и количество заказанных штук.

Сергей Протько: Погодите. Позвольте мне сперва понять как же геттеры и сеттеры могут быть фигней. А инкапсуляция? Вы предлагаете давать прямой доступ к полям класса? Или делать объекты неизменяемыми (см. Википедия "Неизменяемый объект")?

Alexej Simakov: можно делать дела не давай доступ к состоянию объектов вообще. Вот совсем. Собственно это и подразумевается под инкапсуляцией. А когда вы даете доступ к состоянию - то с точки зрения инкапсуляции все... ну чуть лучше чем в варианте с публичными свойствами.

Сергей Протько: в теории вы правы, но если предположить что ваши классы "User, Product, Order" по каким-то причинам имеют суффикс Manager... то результат будет тот же.

1) названия можно было выбрать получше:
-) is_account_available... --> has_account
-) create_new_account --> create_account - new совсем не нужен т.к. вы не будете создавать уже существующий аккаунт.
-) log_in_user --> login - неужели когда-либо в жизни вы будете логинить что-то еще?
-) remove_authentication_for_user --> logout - аутентификация это процесс ее нельзя удалить.
3) управление аккаунтами и управление сессиями это разные вещи, а значит как минимум 2 класса: AccountManager, SessionManager
4) API предложенный вами на самом деле не очень удачный, тот кто им будет пользоватся всегда будет писать шаблонный код: если аккаунта нету - создаем его. В идеале достаточно AccountManager.get(accountName) - внутри которого уже будет зашит бойлерплейт код.
5) account != user, первое это учетная запись, второе - пользователь. Количество связей между ними определяется самим приложением (1 аккаунт - много юзеров, или много аккаунтов - 1 юзер) , но все таки это не одно и тоже

Владимир: нет, UserManager это сэт процедур которые рулят данными User-а. А User - это сущность, которая содержит данные и операции над ними. И она умеет то что должен уметь объект юзера в контексте вашего приложения. Не больше и не меньше. Вот и вся разница.

Если мы возьмем ActiveRecord, завернем в класс менеджер модель данных, уберем суфикс менеджер, то получим почти то же самое.

Сергей Протько: мы практически говорим об одном и том же только... если речь идет о enterprise приложении то классы должны попадать в одну из категорий: model, controller. Их роли такие же как и в паттерне MVC, модель хранит данные а контроллер управляет состоянием модели. Поэтому класса User который хранит данные и имеет набор операций для манипуляции над ними - быть не должно (single responsibility). А все остальное, - это лишь вопрос выбора наименования (пары модель/контроллер): UserDto/User, UserData/User, User/UserManager итд итп... лично я пользуюсь вариантом наименованием схожим на последнюю пару.

p.s. о active record: последний раз пользовался подобным API лет 8 назад, в мире java такое уже давно не актуально... как в других языках обстояит дела я не в курсе

Владимир:

речь идет о enterprise приложении то классы должны попадать в одну из категорий: model, controller

А как же инфраструктура? А модель как же? Это не один объект - это множество объектов формирующих возможно даже не один слой. Рекомендую вам ознакомиться с книгами Эрика Эванса и Крэйга Лармана что-бы осознать что в кровавом "энтерпрзайзе" не все так просто.

Их роли такие же как и в паттерне MVC, модель хранит данные а контроллер управляет состоянием модели.

Популярное заблуждение и подмена понятий.

Для начала давайте определимся что есть ООП и что есть процедурное программирование.

Процедурное программирование - это когда у нас есть данные и есть процедуры. То есть когда мы геттером из одного объекта достаем данные что бы что-то с ними сделать - это процедурное программирование с классами. То есть глобального состояния уже нет и жить нам проще но это еще не ооп. Инкапсуляция нарушена.

ООП - это когда состояние и поведение находятся в одном объекте. То есть если у вас есть код и этому коду нужны какие-то данные - значит это дело должно находиться в одном и том же объекте. Между объектами могут ходить только сообщения, а не данные. Тип "сделай это, сделай то". А объект уже сам разберется как что сделать - все данные у него и так есть (паттерн информационный эксперт).

То есть если вам надо сменить пароль юзеру - вы его об этом просите и даете юзеру все что нужно что-бы он смог сделать это сам. Если надо сформировать заказ используя данные пользователя - просите об этом пользователя и он создает вам новый заказ.

А анемичные модели - то есть тупо модель данных - это антипаттерн. Но если мы говорим в контексте процедурного программирования - то все хорошо.

вернемся к MVC. Для начала вспомним проблему, которую MVC должен был решить в бородатом 79-ом году. В то время появился графический интерфейс, и приложение должно было уметь работать как в консоли например, так и в графическом режиме. Более того, графический интерфейс менялся чаще чем логика, а потому излишняя связанность между UI и логикой вредили делу и усложняли введение изменений (шаблон smart ui).

Так же напомню что в бородатом 79-ом году отрисовать UI - это не сформировать xml-ку. Это работа с объектами. То есть у нас был один объект, который на вход принимал данные и формировал view. Это собственно и был View-объект, который подписывался на изменения в объекте Model (который внутри мог иметь другие объекты и являлся лишь вершиной графа) и занимался формированием представления. Активная вьюшка (потому что она делает дела а не кто-то другой).

Затем контроллер. Задача контроллера - словить событие от вьюшки (в оригинальной публикации 79-ого года упоминаются так же редакторы - контролы на вьюшке генерирующие события), которые описывают действия пользователя с оной, и преобразовать это асинхронное действие пользователя в синхронное сообщение к модели. То есть контроллер никогда и ни при каких обстоятельствах сам с моделью ничего не делает. Он просто просит модель что-то сделать а та уже сама решает делать или нет. Сама сгенерирует событие для вьюшки и вьюшка сама себя обновит.

Это потом с течением времени активная вьюшка оказалась неудобной и ее заменили на пассивную. А между вьюшкой и моделью поставили медиатор - презентер. И называли это MVP. На бэкэнде последние лет 20 больше применяют вариации похожие больше на MVA (Model-Adapter-View, я переставил что бы взаимоотношения были правильными). Возможно вы так-же слышали фразу про "тонкие контроллеры" и сервисный слой.

И соль тут в том что M в этом плане - это точка соприкосновения вашего приложения и UI. Не более. То есть внутри - все что угодно. MVC это только про UI.

Поэтому класса User который хранит данные и имеет набор операций для манипуляции над ними - быть не должно (single responsibility)

SRP штука хорошая, но вы видимо не так ее трактуете. Я трактую SRP как Single Reason to Сhange (и так ее трактует популяризатор SOLID - дядя боб). То есть если вам надо менять userManager просто потому что поменялся UserData (или UserDAo или UserDTO - как хотите) - то явно что-то пошло не так и мы как-то не правильно разделили все на объекты. Мы можем выделить объекты, которые нам необходимы для создяния юзера (UserBuilder например, типичная фабрика). Как минимум потому что нам надо совершить какую-то операцию над тем, чего у нас еще нет. Убираем UserDTO, убираем UserManager, убираем UserData и получаем User.

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

в мире java такое уже давно не актуально... как в других языках обстояит дела я не в курсе

Например если взять data mapper и hibernate. Вы же не будете писать там геттеры с сетерами для сущностей? В чем тогда смысл хибернейт использовать? table gateway нам за глаза в большинстве случаев хватит.

Или вы какие-то еще подходы используете?

Сергей Протько: не совсем понял почему вы решили что user manager должен менятся. В моем случае есть классы UserEntity (DTO), UserDao (DAO), UserManager (Business Logic Controller), понятно что они в какой-то степени связаны: в entity определены поля и связь с хранилищем данных, в DAO логика чтения/записи в хранилище данных, manager - нужен для того чтоб определять бизнеса логику для user. Само по себе изменение одного из них не принуждает к обновлению других, но если у вас добавилось новое поле в табличке то в DAO вам нужно его записать в (вычитать из) хранилище(а) данных, в бизнесс логике откуда-то вытянуть/куда-то положить.

p.s. В моем случае DAO это native sql

p.s. Если же речь идет о Java, и вы используете ORM или JPA то возможно есть смысл в доменных обьектах "User" а-ля EJB 2.0. Правда JPA с EntityManager в принцыпе покрывает большую половину того что вы описали (по функционалу). Правда я предпочитаю jdbc всяким orm фреймворкам.

p.s. single responsibility я трактую дословно - у класса одна ответственность - одна простая задача/цель. Entity (model) - отвечает за представление данных, Dao (controller) - за операции над entity с хранилищем данных, Manager (controller) - только за бизнес логику которая относится только к user. Создавая класс User который будет одновременно и DAO и Entity (контроллером и моделью) я возлагаю на него 3 задачи: модель данных, сохранение данных, это будет подобие active record. Если же "скрестить" Entity и Manager получится domain object, в котором модель данных будет смешана с бизнесс логикой. При наличии сложной бизнесс логики этот обьект рано или поздно постигнет участь god-class, как минимум проблемы с конкурентыми модификациями, постоянные мерджи. Возможно у вас получится локализировать изменения в одном классе, но в целом количество изменений в коде будет такое же как и в моем случае, просто у вас классы будут потолще. Я буду утверждать что ваш подход хуже но мне кажется он имеет место быть только в случае использования ORM фреймвоков у которых нет явно выраженного data access layer или для маленьких проэктов которым плевать на перфоманс.

p.s. и еще, разделение на model и conroller это не я придумал, и взято это не из паттерна MVC а с "еще одна умная книжка", в оригинале речь шла о Dto/VO и controller/manager, я просто упростил для понимания используя слова из MVC паттерна (еще когда читал так запомнил, давно это было поэтому данные о источнике давно утеряны, соль - осталась)

Владимир: во первых поймите правильно - я ни коем образом не хочу сказать что "ваш подход неправильный, есть только один!". Оба варианта - норм. Они просто разные. Это как процедурной и объектно-ориентированное - выбираем под задачу. Если надо моделировать процесс и взаимодействия объектов - объектно ориентированное подойдет лучше. И тогда приходится загоняться именно так как я описывал. А если у нас просто работа с данными - с точки зрения эффективности разработки процедурное неплохо подходит. Ну это так, что бы мы понимали что я не хочу спорить - я иногда сам делаю и так как вы описываете. Просто в последнее время реже.

не совсем понял почему вы решили что user manager должен менятся.

Например мы добавляем какое-то поле для юзера. В этом случае нам надо поправить UserDTO, UserManager и UserDao. Я не прав?

manager - нужен для того чтоб определять бизнеса логику для user.

У меня раньше были менеджеры - теперь я их дроблю на объекты описывающие юзкейсы. Один юзкейс - один объект. Высокоуровневое описание бизнес логики если хотите. Так лучше с точки зрения SRP.

Правда я предпочитаю jdbc всяким orm фреймворкам.

Я SQL использую только для выборок и когда задача в контексте ORM плохо решается (они все же не для всего придуманы а только для маленьких транзакций). Банально скорость разработки увеличивается.

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

При использовании средств вроде Hibernate - не будет. Будет только объектная модель.

При наличии сложной бизнесс логики этот обьект рано или поздно постигнет участь god-class

Просто надо дробить объекты на поменьше.

как минимум проблемы с конкурентыми модификациями, постоянные мерджи.

Эм... немного может не понял о чем вы? Если вы просто про атомарность операций с данными в базе - есть разные варианты вплоть до отказа от изменения состояния (append only структуры). А если мы про GIT - классы всеравно следует делать как-то небольшими. И при отсутствии километров геттеров и прочего мусора - кода выходит на самом неде не так много. Так же всегда можно делигировать какие-то задачи другим объектам.

Я буду утверждать что ваш подход хуже но мне кажется он имеет место быть только в случае использования ORM фреймвоков у которых нет явно выраженного data access layer или для маленьких проэктов которым плевать на перфоманс.

согласен. Хотя тут тоже есть нюансы. Например мы можем использовать row data gateway для того что бы хранить там модель данных и иметь возможность прямых операций над оными. Обычно оно работает значительно быстрее чем мэпперы. Хотя современные мэпперы (во всяком случае те которые использую я) и так довольно быстры.

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

Сергей Протько: я понял суть вашей позиции, однако я уверен что в моем случае классы будут тоньше (но их будет больше). Но и минус моего подхода: изменений тоже будет больше - но они будут точечные (одно поле добавилось/удалилось), одна-две строчки. Единственное что я не уверен что правильно понял так это почему вы такой подход называете процедурным, можно более детально?

Владимир:

для начала крайности:

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

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

Другая крайность - все в объектах. То есть состояние "заперто" внутри объекта и никогда наружу не ходит (никаких геттеров). Состояние дробится на объекты, логика обработки данных так же пихается в те объекты в которых есть нужные данные. Если одна операция нуждается в данных двух объектов - операция делится на части. Если надо взаимодействие с внешним миром - делается объект приоткрывающий внешний мир для объектов чуть-чуть (не dao или там коннекшен к базе а именно отдельная операция маленькая). Так же большая часть объектов имутабельна. То есть если данные поменялись - мы делаем копию объекта с новыми данными (это что б совсем в крайность).

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

Ну то есть когда мы делаем объект хранящий стэйт и объект хранящий "методы" (процедуры) - мы как бы имеем дело больше с процедурным программированием, нежели с ООП. Просто в этом случае наше состояние хотя бы изолировано и мы можем легко проконтролировать кто с чем работает. Значительную часть минусов процедурного программирования мы таким образом устраняем. И в среднем выходит неплохо. Но при большом количестве изменений менять нужно будет больше за счет чего скорость разработки падает. Есть еще такой термин как "лазанья код", это когда что бы поменять что-то на одном уровне нам надо "прорезать" все слои.

Что использовать - дело разработчика. мне вообще кажется что компромис - это комбинирование подходов. Тогда сложные вещи можно сделать в ОО стиле а все остальное - в простом процедурном.

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

Сергей Протько: спасибо за детальный ответ, но на мой вопрос: "где в моем коде процедурное программирование" я все же не нашел ответа. Для себя я вижу только 2 существенные разницы (помимо того что я писал выше), у вас классы User которые содержат в себе модель и контроллер - stateful, у меня UserEntity модель - stateful, UserManager контроллер - stateless. И как следствие функционал ваших классов может менятся в зависимости от их состояния, у меня же все контроллеры - stateless (за редким исключением). А дальше осталось лишь угадать как писать тесты для всего этого. Если в моем случае для тестирования метода надо учитывать лишь данные на входе то в вашем случае еще и состояние.

p.s. я не буду спорить, ваш подход имеет право на существование, но он применим только лишь (субьективное мнение): а) для домашних поделок, где вы вкурсе всего что происходит б) для фриланса (сделал - забыл) в) для маленьких проэктов сильно ограниченных во времени. Ни в одном серьезном проэкте я б не стал подобную структуру использовать, такой код мне сильно напоминает то, что можно увидеть в толстых книжках по EJB 2.0 (т.е. уже не актуально)

p.s.s касательно "лазанья код" - да вы правы, изменение всех слоев это рутина требующая усиленного внимания и концентрации (в прочем как и все что делает программист). Однако код в таком случае максимально прост и читабелен. К тому же есть варианты которые позволяют предупредить изменения всех слоев при изменении структуры model (или субд или еще-чего-то там).