@laravel_pro - страница 369

ты кинул выше пример, я такое видел уже в нескольких проектах только, к примеру, вместо AccountRepository это называлось AccountHelper и там тоже просто куча логики

Andrey

йоооооооопта

Andrey

как тут многа наркоманов

Andrey

с вопросами

Andrey

скидывайте мне бабки)) я буду отвечать на вопросы

Andrey

ну правда

Andrey

за отдельную плату, даже за Вас всё напишу

Dmitriy

ты кинул выше пример, я такое видел уже в нескольких проектах только, к примеру, вместо AccountRepository это называлось AccountHelper и там тоже просто куча логики

Там логика создание юзера и не более. А AccountHelper это вообще не понятно что

Wolf

как тут многа наркоманов

где наркоманы?

Dmitriy

Там логика создание юзера и не более. А AccountHelper это вообще не понятно что

Рабавь его еще классами, пофиг. но он должен создать юзера и точка

Roman

Там логика создание юзера и не более. А AccountHelper это вообще не понятно что

остальные методы, насколько я понял, тоже завязаны на каких то действиях с пользователем

Dmitriy

остальные методы, насколько я понял, тоже завязаны на каких то действиях с пользователем

Я выделил конкретный пример. Окей куда ты денешь этот весь код ?

Roman

Я выделил конкретный пример. Окей куда ты денешь этот весь код ?

я тебе про это и говорю, что обычная вспомогательно-сервисная мусорка, просто обозвали по другому

Wolf

парни, мусорка от вашей перепалки у меня сейчас в голове)))

Wolf

я тебе про это и говорю, что обычная вспомогательно-сервисная мусорка, просто обозвали по другому

какие варианты?

Roman

Я выделил конкретный пример. Окей куда ты денешь этот весь код ?

если код некуда приткнуть, это уже тревожный звоночек

Dmitriy

знаю

Репозитории и сервисы это слоистая архитектура. Можно заменить одну реализацию на другую и ничего не поламается. счас поищу пример

Roman

Репозитории и сервисы это слоистая архитектура. Можно заменить одну реализацию на другую и ничего не поламается. счас поищу пример

то что ты кинул выше - нет

Dmitriy

да , это реализация не более

Wolf

то что ты кинул выше - нет

у тебя одна только критика, какие решения ты предлагаешь?

Dmitriy

Вы вызываем Repository->create

Dmitriy

Он меня всегда критикует

Dmitriy

это норма

Roman

Он меня всегда критикует

ты слишком лично все это воспринимаешь, я в споре учавствую, не более

Dmitriy

Вы вызываем Repository->create

что там внутри приложению по барабану

Roman

у тебя одна только критика, какие решения ты предлагаешь?

меня тоже этот вопрос интересует

Wolf

ты слишком лично все это воспринимаешь, я в споре учавствую, не более

спор, это когда есть аргументы с одной и другой стороны, он предлагает решения, показывает примеры, а ты все что говоришь "мусорка"

Dmitriy

Вообще класическое enterprise-приложение. Строится оно примерно так: Делаем репозитории под сущности — это у нас типа DAL; Делаем сервисы, в которые выносим бизнес-логику — это у нас типа BAL; Пишем контроллеры, которые ничего не делают — это у нас типа Client.

Dmitriy

но и тут есть минусы

Wolf

но и тут есть минусы

какие?

Dmitriy

какие?

Cлишком много boilerplate кода. 40-80% приложения это тупой круд. В итоге сервисы превращаются в классы с кучей методов вида 'дергнуть репозиторий и вернуть результат'

Wolf

Cлишком много boilerplate кода. 40-80% приложения это тупой круд. В итоге сервисы превращаются в классы с кучей методов вида 'дергнуть репозиторий и вернуть результат'

ну и теперь все же вернемся тогда к вопросу, зачем мне необходим репозиторий?))

Dmitriy

ActiveRecord - это нарушение единой ответственности, толстые модели

darkwoolf