Alexey, да, все верно. Многие методы будут с виду "однотипными", просто вы должны смотреть на это с немнго другой стороны. Если вы работаете с сущностью $category, то логично иметь доступ к постам категории. Если вы работаете с сущностью $tag, то так же логино имать доступ к постам связанным с этим тэгом. А иначе, отразив модель базы данных на классы, и не предоставив самому себе соответствующие операции, вы сами себе усложняете жизнь. Обычно, классы репозиториев содержат только методы типа CRUD, getALl, getById, getPaginated и так далее. Классы сервисов затем добавляют каике-то кастомные фрльтры.
Я вам больше скажу. Если вы разделяете все на слои, то вот такого схожего когда будет в десятки раз больше. И это один из недостатков такого подхода. Но понятное разделение когда, окупает накладыне расходы на код.
Ajax - по своей сути, асинхронный. и запросы на сервер могут прийти беспорядочно. Вам нужно самому гарантировать порядок как-то. Функция then, не подходит для этого. Попробуйте функцию success, или complete.
Вопрос, зачем вам нужно вообще только NickName передавать, если можно сущность целиком?
Допустим, передадите NickName, если не гарантируете уникальность, то можете столкнуться с проблемой нескольких пользователей с одним ником. А чтобы гарантировать, нужна дополнительная логика. Если передадите id, то уже лучше, но если надо еще какие-то поля объекта user обработать в классе комментария, то надо тогда по идентификаторы опять искать пользователя. Поэтому сразу передаете созданную сущность и работаете с ней.
Я не математик, просто интересно. А как вы считаете пересечение с покрытием прямой? Вот вы сто прямых нарисовали, и для каждой прямой посчитали в каких точках она пересекает полигон, потом все эти пересечения для ста прямых суммируете и вычисляете минимум для этих же ста но повернутых на угол?
Подсистема в вашем случае, скорее всего, слой сервисов. Тот, что отвечает за бизнес-логику. Можно перенести crud операции в слой репозитариев. И со слоя сервисов, обращаться к ним. Взаимосязь слоев ну и изоляция будет идти через интерфейсы. Как-то так.
Это, конечно, хорошо. Но пока вы не разобрались с modelstate и viewmodels в контексте asp.net mvc. У вас не только с этим проблемы будут. А вообще полно будет проблем. Поэтому я вас советовал разобраться с материалом.
Вот смотрите. У вас должен быть контроллер отвечающий за вашу форму. В Asp.net MVC есть modelstate, это коллекция name=value ваших данных с формы. Она сопоставляется с вашим классов ViewModel. Посмотрите что такое modelstate в контексте asp.net mvc. Далее, имея все эти данные вы можете зараннее подготовить ваши ViewModels так, чтобы они выводились без лишней логики (ну, или почти без лишней).
mitaichik, и я не знаком. Но знаком с asp.net в частности c#. И вот там мы оргинизовывали классы-сервисы выстроенные через интерфейсы, которые были ответственны "только" за бизнес-логику. А из контроллеров мы обращались к этим сервисам. Под сервисами был слой репозитариев. Если в симфони под хелперами понимается тоже слой, то да, разницы никакой. На других проектах были статические классы-хелперы (где-то их менеджарами называют, но суть одна). Вот у меня на это ассоциация сработала.
Я вам больше скажу. Если вы разделяете все на слои, то вот такого схожего когда будет в десятки раз больше. И это один из недостатков такого подхода. Но понятное разделение когда, окупает накладыне расходы на код.