Спасибо за подсказку. Теперь буду делить сервисы на Application Services, Infrastructure Services, Domain Services. Так же выделил еще одну группу View Services с логикой для вьюхи, не связанную никак с бизнесом, не зашиваемую в компонент, не относится к паттерну helper. Например генерирует css анимации для разных вьюх на основе состояния бизнес логики. Да да, у меня и такое встречается =)
Не прибит, в статье про это не рассказал, но менять можно. На один вью может приходиться несколько контроллеров, на один контроллер может приходиться несколько вью. Главное что бы интерфейс сохранялся.
Да вы правы. Логика которая относится к модели нужно размещать в методах модели. В примерах кода так и было сделано. В сервисах помимо склеивание, конкретно у меня есть еще логика по обработке не связанных моделей или массива моделей. Например из массива моделей выбрать подходящие под какие либо условия. Или на основание двух разных моделей получить третью. А также случаи логики не связаны с моделями совсем. Если у вас по другому, расскажите пожалуйста как реализовано у вас.
В статье не хотел усложнять сложными формулировками, но наверное надо будет придумать более удачное описания для этих двух слоев.
Тогда может быть напишите свою статью? Как вы представляете себе ЧА в веб-приложении на любой библиотеке? Вдруг ваш подход и вправду окажется лучше. По обрывкам предложений не понятно.
Хорошо. Если не нравится сравнение с ЧА, давайте по другому. Каким общепринятым названием называется архитектура в которой логика делиться на слои view, controller, model, service, viewModel, repository, entity и так далее...?
Подход который использует VSCode я уже десять лет наблюдаю в ASP.Net. Так что вариант «своя архитектура» не учитывается.
Размеры веб приложений растут. А решений для написания больших приложений нет. Поэтому люди обращаются к практикам из других систем. Поэтому таких статей будет только больше.
Боюсь если соблюдать всё что вы написали, то это отпугнет вообще всех фронтенд разработчиков. Можно конечно и интерфейс писать на каждый класс и разделение слоев делать более «эталонным» и вообще сделать все «энтерпрайзненько», но это не решит никаких проблем проекта, только раздует техдолг до огромных масштабов.
Поэтому не надо никому доказывать что вы лучше поняли книгу, тем более что автор книги не автор этой архитектуры. И не надо так радикально подходить к соблюдению всего что написано в книге. Достаточно взять только то что решает твои проблемы и не создает проблем с поддержкой и уже получится хороший продукт.
Поступок с Angular 1, когда фреймворк просто бросили и написали другой, нанес мне психологическую травму. С тех пор я не доверяю никакому Angular =).
Статья в первую очередь для тех кто уже писал на других платформах и хочет переключиться на веб разработку. Судя по статьям на хабре за последнее время таких весьма много. Кроме того многие Angular разработчики не видят будущего в этом фреймворке, и так же хотят перейти на более популярный с сохранением опыта.
Я знаю что 60% разработки на реакте это редакс. А так я предложил успешную концепцию которая справляется с любой задачей по гибкости и производительности. И если хотя бы часть сообщества не побоится использовать такой подход, то это уже хороший шаг к наведению порядка на реакте.
Полусайт-полуприложение. К тому же весьма дорогое по стоимости поддержке серверов. Отдать клиенту статику и отрендерить на клиенте приложение в сотни раз дешевле.
На самом деле это стереотип. На беке достаточно иметь защищенное АПИ, для любых клиентов и интеграций. А выдает ваш бек html или json на безопасность никак не влияет.
Смотря что и как писать. Если просто провалидировал и отправил на сервер или получил с сервера и показал что пришло, то да, излишне. А если писать Приложение с большой буквы, то очень даже помогает =).
Согласен что эталонной нет. В том же Asp.Net Core и JavaSpring между ними есть разница. Но тут главное не дословное следование книжке, а сама суть процесса по разделению кода.
Я работаю в команде. И обычному фронту вообще тяжело понять что такое Service и почему нельзя на jquery скрипт написать. Поэтому я стараюсь не усложнять такими подробностями. Ведь в любом случае это Service =)
Это скорее касается организации кода, нежели архитектуры. У Мартина есть свое мнение, у меня свое. Я стараюсь придерживаться организации кода как по ссылке. У такого подхода тоже свои глубокие корни.
Да, Мартин не является автором такого подхода, так же как и Рихтер не является автором CLR. Но Мартин написал популярную книгу рассказывающую о таком подходе и дал название такому подходу, которое стало общепринятым. И Чистая Архитектура дополняет слоистую архитектуру.
Clean Architecture в коде никогда не упоминается. Суть чистой архитектуры в организации кода по слоям View, Controller, Service, Repository, Model, ViewModel. Все они у вас перед глазами сразу по ссылке.
В статье не хотел усложнять сложными формулировками, но наверное надо будет придумать более удачное описания для этих двух слоев.
Подход который использует VSCode я уже десять лет наблюдаю в ASP.Net. Так что вариант «своя архитектура» не учитывается.
Поэтому не надо никому доказывать что вы лучше поняли книгу, тем более что автор книги не автор этой архитектуры. И не надо так радикально подходить к соблюдению всего что написано в книге. Достаточно взять только то что решает твои проблемы и не создает проблем с поддержкой и уже получится хороший продукт.
Статья в первую очередь для тех кто уже писал на других платформах и хочет переключиться на веб разработку. Судя по статьям на хабре за последнее время таких весьма много. Кроме того многие Angular разработчики не видят будущего в этом фреймворке, и так же хотят перейти на более популярный с сохранением опыта.
Я знаю что 60% разработки на реакте это редакс. А так я предложил успешную концепцию которая справляется с любой задачей по гибкости и производительности. И если хотя бы часть сообщества не побоится использовать такой подход, то это уже хороший шаг к наведению порядка на реакте.
Все данные для переиспользования распологаются в сервисе.
И самый главный момент, книга написана по уже имеющийся архитектуре, а не код организовали по книге.