> весь код в название вывести А вам жалко? Перф

от этого не пострадает.

> затраты времени, на то что человек написал до ревью, потом ревьювер потратил время
Это процесс разработки. Если постоянно так делает один человек, то мб с ним надо расстаться?
А если делает несколько человек в команде - то стандартны надо актуализировать?
Такие проблемы всегда подсвечивают на то, что процессы можно улучшить.

> Не улучшается читабельность, наоборот падает и сильно
Как скажете. Полагаю, это субъективно.

> а когда начинают идти классы GetProductWithDiscountAndWithNetCost... и такое прочее?
1. В репозиторях это выглядело бы более страшно.
2. Тогда надо задуматься, а правильную ли мы технологию для доступа к БД выбрали. Лично я считаю, что надо использовать EF всегда, пока не начнётся проблем с перфом. Вы вон, сами говорите, что 80% - это CRUDы.
:)

> весь код в название вывести А вам жалко? Перф от этого не пострадает. Я же привел пример, как потом эти километровые названия читать то? > затраты времени, на то что человек написал до ревью, потом ревьювер потратил время Это процесс разработки. Если постоянно так делает один человек, то мб с ним надо расстаться? А если делает несколько человек в команде - то стандартны надо актуализировать? Такие проблемы всегда подсвечивают на то, что процессы можно улучшить. Это явно подвечивает то что сам подход надо менять что мы и сделали, и не жалеем, продуктивность как написание нового так и на внесения изменений выросла в разы, это я считаю показатель. > Не улучшается читабельность, наоборот падает и сильно Как скажете. Полагаю, это субъективно. Естественно, мне очень некомфортно листать простыни из десятков тысяч классов с дикими длиннущими названиями, и что то там пытатся найти, это еще затраты времени в пустую. >1. В репозиторях это выглядело бы более страшно. А зачем на такое писать репозиторий? Сразу на месте и получим что надо. слоенки то нет слава богу уже давно. 2. Тогда надо задуматься, а правильную ли мы технологию для доступа к БД выбрали. Лично я считаю, что надо использовать EF всегда, пока не начнётся проблем с перфом. Вы вон, сами говорите, что 80% - это CRUDы. А тут я вообще не понял, при чем тут перф, про него вроде речь то и не шла в разговоре...

А можно суть вашей баталии узнать) вы спорите, надо ли использовать слои в монолите? Или что

Отмотайте на 4 часа назад

Вкратце: Я вбросил, что Repo + UoW нужно забыть как страшный сон и пользоваться современными практиками. Vertical Slice и прочим красивым. Нашлись люди, которые не согласны, но доводов в их пользу почти нет. Но довольно много отговорок.

Человек топит как я понял за единообразие в проекте, чтобы все функциональности делались одиноково, ну под это одинаково команды и запросы продвигает, как я понял SQRS. А я стою на том каждая функциональность должны быть построена тем образом который конкретно ей лучше подходит, и не должно быть единых правил построения в проекте.

Стикер

CQRS. И нет. Я за то, что бы код после вас был поддерживаемым и читабельным.

Здарова, DbContext - это UoW и есть. А тут речь о своих реализациях.

Он поддерживаемый и читабельный, красивый и комфортный.