Разделение приложения на слои

Обсуждаем, как правильно строить приложения
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Разделение приложения на слои

Сообщение zelenin »

nepster писал(а):Вы наверно не совсем понимаете что я пытаюсь сделать.
Я не пытаюсь лепить велосипед или делать симфони, я просто пытаюсь взять yii2 и выработать удобный подход к разработке.

Какие есть проблемы на сегодняшний день:
1) В лучшем случае все лепят код в одну модель. В результате чего получается 1 модель с 25 сценариями и 5000 строк кода, это поддерживать крайне тяжело. Причем это в лучшем случае, в худжем все это будет раскидано по вьюшкам и контроллерам.

2) Когда нарастает кодовая база и нужно что-то добавить или изменить, то это превращается в сущий ад, так как например если у вас есть выборка из базы например всех статей, а потом понадобилось учитывать статус, то если эта выборка не инкапсуляция в метод, нужно искать по всему проекту где это находится и лепить с коп везде в лучшем случае.

3) Плюс ко всему в юи есть очень тупняковые штуки, которые нужно использоваться очень аккуратно. Я когда допилю проект, закину обзор с какими проблемами я столкнулся при разработке.

4) В документации почти нет ничего про бест практик в реальных проектах. Все ограничивается простенькими примерчиками, как любят говорить, на уровне "брожика".


От сюда следует:
1) Нужно сделать красивый подход в отношении структуры принимая правила игры yii2 (привет zelenin =)).
2) Где-то я смотрел видео выступления Александра Макарова по теме yii2, где была замечательная фраза: "Yii2 - это другая ниша (в контексте сравнения с симфони)"
3) Что касается зависимостей, ну не возможно от них избавиться на все 100%, а те кто считают, что возможно, значит не решали обезбашенные задачи (привет сетевому маркетингу и mlm матрицам).
4) Попытка сделать супер независимый код, выйдет в избыток абстрактности, что в итоге будет буксовать приложение, а потом все будут плакать, что php говно (кто хочет поспорить, пожалуйста кидайте ссылки на свои гит аккаунты, я с радостью).
5) Когда жмут сроки или вселенская лень, никто не знает про TDD, BDD, SOLID, DDD и прочие сокращения. Я еще не разу не видел ни один проект, который бы был сделал идеально по всем стандартам, библиотеки да, хелперы, виджеты - да. Но чем больше проект тем больше в нем говна.

ФормМодел и СирчМодел описываются в документации по yii2.
Мне бы еще не помешало разработать концепцию как красиво отделять выборку и возможно стороннюю логику.
очередная вода. Я так понял тебе нужны хелперы для собрания методов и сервисы со связанной логикой. Ну та ки делай.

lynicidn
Сообщения: 2222
Зарегистрирован: 2014.05.24, 15:12

Re: Разделение приложения на слои

Сообщение lynicidn »

Sam Dark писал(а):При этом слоить можно замечательно и в Yii. Это особо ничем не отличается от слоения в других фреймворках. И нет, для этого не обязательно использовать Doctrine.

При этом надо понимать, зачем это делается, как это делается и, главное — зачем оно вам.
не совсем можно слоить ар в уии
а в доктрине нет логики кроме выборки, там паттерн репозиторий, а у нас это МОДЕЛЬ

Аватара пользователя
samdark
Администратор
Сообщения: 9361
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Разделение приложения на слои

Сообщение samdark »

1) Лепите в несколько. Юзайте модели форм. Выделяйте доменный слой, если в этом есть смысл, переносите общую логику в компоненты, виджеты, отдельные PHP-классы.
2) Случилось — выделяйте в метод.
4) Потому что все проекты разные. Все команды разные. Практики и принципы у всех тоже разные.

Рефакторите постоянно и как только потребуется.

Про выводы:

1) Для себя выработать можно что угодно. Если оно работает — это хороший, подходящий вам и вашей команде подход. Я лично пишу как придётся (относительно) и, как только начинает становиться неудобно, рефакторю. Возможно, у меня это работает потому как я хорошо чувствую будущие проблемы. Если для вас это не так, придумывайте себе более строгие рамки.
2) Да, это действительно несколько другая ниша и другой подход. Менее академичный.
3, 4) Возможно. В итоге у вас получился крутая такая луковица с 100 слоями. «Кто его раздевает, слёзы проливает...». Не факт, что это всегда лучше зависимостей. Но и не факт, что всегда хуже.
5) Лень — зло. Код сам по себе не пишется. Фекалии сами по себе из проекта не уходят.

Аватара пользователя
samdark
Администратор
Сообщения: 9361
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Разделение приложения на слои

Сообщение samdark »

lynicidn
Кто мешает сделать репозиторий для моделей AR? Не вызывать нигде и никогда вне него save(). Ввести интерфейсы для сущностей, реализовать их в AR-классах. Единственное отличие от чистеньких value-объектов будет в наличии технической возможности это нарушить. Вербальный контракт тоже можно соблюдать...

Аватара пользователя
vova07
Сообщения: 1004
Зарегистрирован: 2012.11.29, 14:52
Откуда: Chisinau, Moldova

Re: Разделение приложения на слои

Сообщение vova07 »

Если позволите внесу свои 5 копеек:
Я частично согласен с "zelenin"-ым, но в тоже время и с "SamDark"-ом. Ну и с другими участниками тоже.

Как сказал Александр Макаров на Уии тоже можно писать слоями, и это реально так. Если судить с точки зрения ДДД то нам не важно какой фрейм будет в итоге использоваться, по этому из этого исходит что и УИИ нам по сути подходит. Но тут есть пара проблем, если даже это возможно это очень трудно, хотя-бы потому что не все компоненты фрейма мы можем контролировать, один из реальных примеров это сам принцип работы фрейма, симфони это HTTP фреймворк, в то время как Уии это MVC фрейм. Эти корневые отличия вынуждают костылить чуток в ДДД стиле с использованием Уии.

В тоже время я не могу согласится с "SamDark"-ом касательно того что не всегда слои хорошие. Это не так, и всегда это хорошо. Аргументирую: слои в том виде которые обсуждаются в этой теме это обычные патерны которые используются в одном или в другом месте. Чтобы убедится что например команда и репозиторий это всегда хорошо, то можно взять обычный реальный пример: Интернет-магазин. Если его решили делать на фреймворке то это сразу означает что это не обычный магазин, и именно для таких целей используется фрейм, что уже само по себе говорит о том что проект уже не простой а более сложный. Теперь к сути: Если мы сделаем регистрацию с тем подходом что предлагают сейчас в Уии, то мы получаем много проблем. А именно: в один прекрасный день нам нужно подарить дисконтный купон при регистрации пользователя. На второй день менеджер захочет начислить еще по 10 баксов тем кто регистрируются в понедельник. На третий день нам уже нужно в момент регистрации добавить 5% скидки на первые 5 заказов, ну и так далее. Если как я говорил мы будет использовать то что есть щас то мы тратим в 2 раза больше времени так как мы должны написать новый функционал и еще отрефакторить старый код, + может быть подправить тесты чтобы все работало как надо. Это очень и очень плохо, так как владелец переплачивает. Вы тратите его деньги только потому что сразу не сделали все правильно. Если бы сразу были введены "События" + Команды то мы бы за считаные минуты решили бы любую задачу. Если кто-то скажет что это придуманные примеры, то я с вами тоже не соглашусь, так как в наши дни интернет это уже не простой сайтик и бложик, это сложные ЦРМ, Крупные порталы, Бизнес инструменты итд, все остальное просто НЕ НУЖДАЕТСЯ в фреймворках а знацит там и ЦМС-ок хватает и они за пределами темы.

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

А проектов 100% правильных нет в публичном доступе так как за них люди платят очень и очень много бабла, и конечно в таких условиях никто никогда не опубликует исходники. А если TDD, BDD, SOLID, DDD и другие сокращения вам не подходят только потому что у вас не времени, то это проблема исключительно программиста, или же такие проекты реально в них просто не нуждаются и они могут быть написаны на коленке.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Разделение приложения на слои

Сообщение zelenin »

vova07 писал(а):А если TDD, BDD, SOLID, DDD и другие сокращения вам не подходят только потому что у вас не времени, то это проблема исключительно программиста, или же такие проекты реально в них просто не нуждаются и они могут быть написаны на коленке.

Аватара пользователя
samdark
Администратор
Сообщения: 9361
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Разделение приложения на слои

Сообщение samdark »

симфони это HTTP фреймворк, в то время как Уии это MVC фрейм. Эти корневые отличия вынуждают костылить чуток в ДДД стиле с использованием Уии.
Можно пояснить этот момент? По мне так кроме того, что в гайде Yii называется MVC, а Symfony не MVC, разницы особо нет. И там и там есть request-response, что мы туда суём и как — дело юзера. Да, конечно оно преподносится сильно по разному, но технически сходно. Или нет?
Теперь к сути: Если мы сделаем регистрацию с тем подходом что предлагают сейчас в Уии, то мы получаем много проблем. А именно: в один прекрасный день нам нужно подарить дисконтный купон при регистрации пользователя. На второй день менеджер захочет начислить еще по 10 баксов тем кто регистрируются в понедельник. На третий день нам уже нужно в момент регистрации добавить 5% скидки на первые 5 заказов, ну и так далее. Если как я говорил мы будет использовать то что есть щас то мы тратим в 2 раза больше времени так как мы должны написать новый функционал и еще отрефакторить старый код, + может быть подправить тесты чтобы все работало как надо.
Это ещё можно поспорить, что быстрее: сделать послоёней сразу и навернуть после определённую фичу или сделать сразу просто, чуть порефакторить и сделать эту же фичу. Бывают такие изменения, ради которых и наш слоёный пирог приходится выкинуть и сделать новый. Потому что ну никак не думали, что такое вообще возможно.

Ну и даже в случае начала без слоёв если реально нужно, слои возникнут в процессе первого же рефакторинга. Вот только будут они чётко по делу и очень тоненькие. Рефакторинг, как и написание и правка тестов — всегда часть выполнения практически любой задачи. Если не рефакторить попутно нужные вещи, слоёное приложение или нет, оно довольно стремительно скатится в очень плачевное состояние.
Если бы сразу были введены "События" + Команды то мы бы за считаные минуты решили бы любую задачу.
Вспомнились сразу хуки-события в Drupal. Вроде сделать можно всё, что душа пожелает и не надо трогать оригинальный код, но выглядит это частенько чудовищно, очень сложно для отладки и понимания.

В CMS это ещё оправдано, потому что код публичный, ломать его нельзя. Но в своём проекте если и использовать события, то очень очень умеренно. Большинство задач можно решить и без них. Получится тупо, не слоёно, в одном месте и очень просто и понятно. Да, мы в это упрёмся, но во-первых, не сейчас, а во-вторых, код нам, в отличие от публичных CMS, рефакторить с изменением API можно.

Несмотря на то на сколько один или другой фреймворк отличается от другого мне кажется нам просто нужно писать правильно код. Под правильно я подразумеваю использования тех патернов там где это реально нужно, но никак не все сразу. И как сказал "xoma" то что работает для "Лары", без проблем работает и для Уии это прямое доказательство того что писать нужно правильно везде так как эти правила универсальны.
Общие принципы универсальны. Их применение — нет. Надо ещё подумать, чтобы понять, что, где, как и когда применить. Серебряных пуль у нас нет, иначе не было бы и профессии.
А если TDD, BDD, SOLID, DDD и другие сокращения вам не подходят только потому что у вас не времени, то это проблема исключительно программиста, или же такие проекты реально в них просто не нуждаются и они могут быть написаны на коленке.

Не «на коленке», а «без ненужного для именно этих проектов усложнения» ;)

Аватара пользователя
creocoder
Сообщения: 138
Зарегистрирован: 2010.01.24, 05:29
Откуда: Тамбов

Re: Разделение приложения на слои

Сообщение creocoder »

vova07 писал(а): В тоже время я не могу согласится с "SamDark"-ом касательно того что не всегда слои хорошие. Это не так, и всегда это хорошо. Аргументирую: слои в том виде которые обсуждаются в этой теме это обычные патерны которые используются в одном или в другом месте. Чтобы убедится что например команда и репозиторий это всегда хорошо, то можно взять обычный реальный пример: Интернет-магазин. Если его решили делать на фреймворке то это сразу означает что это не обычный магазин, и именно для таких целей используется фрейм, что уже само по себе говорит о том что проект уже не простой а более сложный. Теперь к сути: Если мы сделаем регистрацию с тем подходом что предлагают сейчас в Уии, то мы получаем много проблем. А именно: в один прекрасный день нам нужно подарить дисконтный купон при регистрации пользователя. На второй день менеджер захочет начислить еще по 10 баксов тем кто регистрируются в понедельник. На третий день нам уже нужно в момент регистрации добавить 5% скидки на первые 5 заказов, ну и так далее. Если как я говорил мы будет использовать то что есть щас то мы тратим в 2 раза больше времени так как мы должны написать новый функционал и еще отрефакторить старый код, + может быть подправить тесты чтобы все работало как надо. Это очень и очень плохо, так как владелец переплачивает. Вы тратите его деньги только потому что сразу не сделали все правильно. Если бы сразу были введены "События" + Команды то мы бы за считаные минуты решили бы любую задачу. Если кто-то скажет что это придуманные примеры, то я с вами тоже не соглашусь, так как в наши дни интернет это уже не простой сайтик и бложик, это сложные ЦРМ, Крупные порталы, Бизнес инструменты итд, все остальное просто НЕ НУЖДАЕТСЯ в фреймворках а знацит там и ЦМС-ок хватает и они за пределами темы.
Задача элементарная и решается на Yii без каких либо проблем классическим "неправильным" способом. Причем сразу. Через 5 минут как только менеджер выразил свои пожелания, без слома тестов и рефакторинга. Основная соль в том что RAPID фреймворки нужно тоже уметь правильно использовать.
vova07 писал(а): А проектов 100% правильных нет в публичном доступе так как за них люди платят очень и очень много бабла, и конечно в таких условиях никто никогда не опубликует исходники. А если TDD, BDD, SOLID, DDD и другие сокращения вам не подходят только потому что у вас не времени, то это проблема исключительно программиста, или же такие проекты реально в них просто не нуждаются и они могут быть написаны на коленке.
TDD + BDD это всегда не плохо, когда есть время. SOLID полезен, но в RAPID фреймворках сознательно не соблюдается, ради баланса в скорости разработки. DDD... если проект соответствующего уровня, в комманде 50 человек, есть мешок денег и год времени, да не вопрос. Ах, да, чуть не забыл. Пару светил DDD серьезного уровня с многолетним опытом разработки по DDD методике тоже неплохо в такую команду прихватить. Неправильное DDD это как неправильная хирургическая операция :D Любой хороший RAPID всегда будет лучше хренового DDD и по времени и по деньгам.
Последний раз редактировалось creocoder 2015.08.18, 18:00, всего редактировалось 1 раз.

Аватара пользователя
SiZE
Сообщения: 2699
Зарегистрирован: 2011.09.21, 12:39
Откуда: Perm
Контактная информация:

Re: Разделение приложения на слои

Сообщение SiZE »

Фигассе вас от темы унесло. )
в поиске работы

lynicidn
Сообщения: 2222
Зарегистрирован: 2014.05.24, 15:12

Re: Разделение приложения на слои

Сообщение lynicidn »

SiZE писал(а):Фигассе вас от темы унесло. )
:roll: все вроде в теме

Аватара пользователя
vova07
Сообщения: 1004
Зарегистрирован: 2012.11.29, 14:52
Откуда: Chisinau, Moldova

Re: Разделение приложения на слои

Сообщение vova07 »

Sam Dark писал(а):Можно пояснить этот момент? По мне так кроме того, что в гайде Yii называется MVC, а Symfony не MVC, разницы особо нет. И там и там есть request-response, что мы туда суём и как — дело юзера. Да, конечно оно преподносится сильно по разному, но технически сходно. Или нет?
По сути вроде похожи но на самом деле не совсем так. Я сейчас рассуждаю исключительно из того что есть на данный момент.
В Уии есть конкретная привязка на MVC структуру (вроде припоминаю что были планы это исправить), то есть нельзя избавится полностью от контроллеров, те же представления конечно же можно не юзать но логика фреймворка как-бы намекает что это предпочтительно. Модели конечно можно не использовать, но вся мощь фреймворка заложена в них. В то же время в HTTP фреймах, идея заложена в непосредственной обработке запроса/ответа и не важно где это конкретно выполняется, в MVC структуре, в одном файле, в конфиге, итд.
И там и там есть плюсы. Хотя лично мне кажется что для всего почти хватает PSR-7 реализация + middlewares патерн.


@creocoder конечно же все решается, я даже не спорю, я просто хотел донести тот факт что в определенных моментах учитывая нынешние реали веб разработка это не чисто написание кода, это решение бизнес задач. А в таких случаях лучше всего решать проблемы правильно. Да и я никогда не говорил что RAPID принцип это плохо, это очень даже хорошо, для прототипов, для мелких сайтиков, да даже для крупных проектов где по сути бизнесс логика ну просто очень скромная, пара десяток "юз кэйсов", но по сути фреймы обычно используются для нетривиальных задач.
Также я согласен с вами касательно RAPID vs DDD и вагон денег. Да согласен что для правильного ДДД нужен опыт и специалисты, НО никто не мешает использовать частично определенные практики, и решать проблемы быстро и красиво.

Но еще есть один момент, который возможно не все уловили в моем тексте: "я рассуждаю исключительно из содержания текущей темы" а именно как я понял люди под слоеной разработкой в ЭТОЙ теме подразумевают пару паттернов как репозиторий, сервис, и модель. По этому мои слова сказаны в рамках этих понятий, если же мы говорим о "Hexagonal Architecture" и подобные принципы то я прокомментирую это дело чуток по другому.

Что хочу сказать напоследок?!
DDD хорош там где реально много бизнес правил. RAPID это очень хороший принцип и он тоже хорош в своей нище и с этим нельзя поспорить, но есть один факт: нельзя утверждать что применения патернов и общепринятых практик в правильных ситуациях это плохо.

ПС: Я все еще фанат УИИ, так что не пинайте. :)

Аватара пользователя
samdark
Администратор
Сообщения: 9361
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Разделение приложения на слои

Сообщение samdark »

Технически в Yii привязки ни к чему нет:

Код: Выделить всё

<?php
require 'vendor/autoload.php';
require 'vendor/yiisoft/yii2/Yii.php';

class MyApplication extends \yii\web\Application
{
    /**
     * @inheritdoc
     */
    public function handleRequest($request)
    {
        $response = $this->getResponse();
        $response->data = 'Hello!';
        return $response;
    }
}

(new MyApplication([
    'id' => 'MyApplication',
    'basePath' => __DIR__
]))->run();
Реализация request-response у нас на данный момент схожа с PSR-7 с небольшими отличиями (потому как была сделана сильно раньше).

Аватара пользователя
vova07
Сообщения: 1004
Зарегистрирован: 2012.11.29, 14:52
Откуда: Chisinau, Moldova

Re: Разделение приложения на слои

Сообщение vova07 »

Как руты можно быстро реализовать ?

То есть примерно вот такое:

Код: Выделить всё

<?php
$app = new \Slim\Slim();
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name";
});
$app->run(); 

Аватара пользователя
samdark
Администратор
Сообщения: 9361
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Разделение приложения на слои

Сообщение samdark »

Шорткаты для роутера и анонимки прямо в index.php преподносятся в каждом из микрофреймворков как что-то крутое и полезное, однако в реальных приложениях на том же Slim я ни разу их не встречал. Поэтому их нет из коробки в Yii2. Но реализовать можно и не очень сложно:

Код: Выделить всё

class MyApplication extends \yii\web\Application
{
    private $callbacks = [];

    /**
     * @inheritdoc
     */
    public function handleRequest($request)
    {
        list ($route, $params) = $request->resolve();
        if (preg_match('~callbacks/(\d+)~', $route, $matches) && isset($this->callbacks[$matches[1]])) {
            $result = call_user_func_array($this->callbacks[$matches[1]], $params);
        } else {
            throw new \yii\web\NotFoundHttpException();
        }

        $response = $this->getResponse();
        $response->data = $result;
        return $response;
    }

    public function onGet($pattern, callable $callback)
    {
        // тут можно сделать свой класс URLRule, но мне было лениво
        // поэтому грязный хак на скорую руку
        $callbackIndex = count($this->callbacks);
        $this->callbacks[$callbackIndex] = $callback;
        Yii::$app->getUrlManager()->addRules([
            $pattern => 'callbacks/' . $callbackIndex
        ]);
    }
}

$app = new MyApplication([
    'id' => 'MyApplication',
    'basePath' => __DIR__,
    'components' => [
        'urlManager' => [
            'enablePrettyUrl' => true,
            'showScriptName' => false,
        ],
    ],
]);

$app->onGet('hello/<name>', function($name) {
    return 'Hello, ' . $name . '!';
});
$app->run();
 
Естественно, MyApplication и его дефолтный конфиг можно скрыть. Останется:

Код: Выделить всё

$app = new MyApplication();
$app->onGet('hello/<name>', function($name) {
    return 'Hello, ' . $name . '!';
});
$app->run();
 

Аватара пользователя
samdark
Администратор
Сообщения: 9361
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Разделение приложения на слои

Сообщение samdark »

Ох, унесло меня в оффтоп :)
нельзя утверждать что применения патернов и общепринятых практик в правильных ситуациях это плохо.
Что факт, то факт. Главное, чтобы паттерн помогал в этой самой правильной ситуации, а не был применён чтобы было и потому что без него не круто.

nepster
Сообщения: 838
Зарегистрирован: 2013.01.02, 03:35

Re: Разделение приложения на слои

Сообщение nepster »

Тоесть фактически мы приходим к тому, что: Кому как удобно тот так и делает?

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Разделение приложения на слои

Сообщение zelenin »

nepster писал(а):Тоесть фактически мы приходим к тому, что: Кому как удобно тот так и делает?
а так и есть везде. нигде нет какой-то навязанной структуры.

nepster
Сообщения: 838
Зарегистрирован: 2013.01.02, 03:35

Re: Разделение приложения на слои

Сообщение nepster »

zelenin писал(а):
nepster писал(а):Тоесть фактически мы приходим к тому, что: Кому как удобно тот так и делает?
а так и есть везде. нигде нет какой-то навязанной структуры.
ну мы же оба понимаем во что это в результате выливается.

Сколько разработчиков пишут тесты ? 1%, может быть 5% ?
Сколько разработчиков поддерживают принцип "и так сойдет" или "оно работает, лучше это не трогать" ?

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

Аватара пользователя
samdark
Администратор
Сообщения: 9361
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Разделение приложения на слои

Сообщение samdark »

Фактически да. Исключение — командная работа. Внутри команды бывает просто необходимо установить какие-то рамки, правила или стиль. Но какие — зависит целиком от команды и проекта. Это не фреймворку решать.

Ну а про слои, DDD и всё остальное, конечно, Yii очень не хватает статей с примерами и объяснением, почему это делается и для чего оно может пригодиться. Я пока написанием этих статей заняться не смогу. Если кто-то из понимающих, отметившихся в данной теме (да и остальных тоже), напишет, буду очень благодарен.

Аватара пользователя
samdark
Администратор
Сообщения: 9361
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Разделение приложения на слои

Сообщение samdark »

nepster
Выдавайте интересующие вас вопросы. Только менее абстрактные и масштабные. Не «как мне структурировать мой доменный слой» или «как не погрязнуть в говнокоде», а «куда положить вот этот код» или «вот это делать в модели, вию или контроллере?». Отвечу и закину в гайд в виде примечаний.

Если попытаться впихнуть «как надо слоить и надо ли» в гайд, там набежит на серию книг.

Закрыто