Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>А откуда мнение что код с кучей dto и мапперов менее запутанный и проще поддерживается чем без него?
G>>Я вот проводил замеры maintainability index для кода с разделением и без и не код с разделением стабильно проигрывал.
G>>Это потом что maintainability index зависит от halastead volume, по сути от нормированного количества строк.

G>>В целом я не понимаю как увеличение количества кода может положительно сказываться на стоимости поддержки.

S>Ну на счет разделения объектов (для каждого слоя свой набор объектов) + мапперы — вижу только один смысл — когда над каждым слоем работает отдельный человек и чтобы не ждать пока Вася изменит свой слой — Петя может уже создавать и тестировать. А уже отдельный чел. занимается исключительно мапперами и интеграцией слоев в единую систему.
Это возможно если для реализации требований нужно менять верхние слои, при этом не трогая нижние . Но при разделением как рекомендует domain model или onion/hexagon/clean architecture это невозможно, так как почти каждое значимое изменение требований приведет к изменению не только представления, но и хранимых данных, и, соответственно, всех слове между ними.


S>Других плюсов особо не видно. Т.е. если у вас нет строгого разделения труда — то нет смысла и в строгом разделении объектов. Но когда несколько человек работают над системой одновременно и каждый занимается своим слоем — появляется смысл все-же.
На практике удобнее не горизонтальное, а вертикальное деление. Например asp.net identity. Показывает как можно сделать отдельную функциональность, котрая содержит как работу с базой, так и часть представления, при этом достаточно хорошо кастомизируется и интегрируется с другими частями

Но конечно в asp.net identity вы не найдете паттерном clean archtecture

S>А вот строгость в придерживании архитектуры, как то принято писать ViewModel — но ты для отдельных форм это не применяешь (а просто напрямую вызываешь api-методы и базу из обработчика кнопки) — тут есть минус. А именно, код становится сложнее поддерживать, сложнее дорабатывать.

Я, честно, не видел современных приложений построенных по такому принципу. За счет того что везде есть data binding проще иметь промежуточный объект, к которому привязывается форма, а внутри него уже дергать методы БЛ. А если мокать бл для объекта, то можно удобно тесты писать

S>>>И что заказчику делать, если разработчик три дня исправляет простой баг а после исправления создает новый баг? Выгонять?
G>>Чтобы ответить на этот вопрос надо понимать почему так происходит.

S>Порядок. Вот в вещах порядок — можно все разложить по коробочкам (особенно поймут электронщики). А можно как бы не заморачиваться и все вывалить в одну большую кучу.
Если бы «раскладывание по коробочкам» было бесплатно, то все бы так делали. Но почему-то нет. См тот же asp.net identity

S>Когда тебе нужно найти деталь — то по коробочка найдешь сразу (при грамотном структурировании). А кучу нужно перебирать каждый раз с нуля.
Мне кажется это миф, все равно надо читать код и делать go to definition. И чем меньше кода и перекладываний объектов, тем проще. По крайней мере я на себе ни разу не замечал улучшение чтения от разделения.

S>>>Ок, выгнал (а скорее тот сам ушел еще до того, как проблема стала очевидной). Берет нового — новый говорит что нужно все переписывать с нуля. Берет другого — тот делает вид что работает, месяц делает вид, два — говорит что еще разбирается в проекте. А потом начинает работать еще медленнее.
G>>Если ты заказчик, который не разбирается в процессе, то плати только за результат, а не за время

S>Но тогда ты просто перекладываешь проблему разработки и чистоты кода на чужие плечи. А проблема эта никуда не ушла. Лучше разберись сам и научить чистоте кода без привлечения посредников.
Далеко не каждый сам способен разобраться