T_STV,

про ViewModel BLL ничего не знает.

T_STVВот и я это говорю. ViewModel - это уже клиентская часть. но мне говорят нафига мы будем лишние движения делать, проще сразу из BLL вытаскивать ViewModel.

ох огребёте же потом проблем...

ПарамонhVosttпро ViewModel BLL ничего не знает.
Хорошо бы, вот только половина выборок создаются именно для View.

так чего мелочиться, отдавайте из BLL сразу JSON

Парамон,

зависимость. при использовании отдельных ViewModel, точка зависимости V-M будет сосредоточена исключительно в контроллерах. если пойти дальше, то и вообще в маппере.

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

на BLL-классы эти вещи вешать категорически нельзя. а кто так делает, культяпки на плаху и долой их

Парамон,

а проблемы начнут сразу же возникать на предмет, где же этот нужный с*ка-класс определён, и рыскать по моделям, а не найдя в BLL. классно, чо.

некоторые отдельные привыкли считать, что программист намертво привязан к своему проекту и у него фантастически феноменальная память. на счёт того, что программист человек, его могут уволить и заменить другим, или он просто подзабудет детали реализации, особо не заморачиваются. главное быстрей быстрей что-нибудь выпустить, чтобы хоть как-то ворочалось

ПарамонДавай ближе к практике.
Допустим есть грид, который отображает некий срез данных. Делаю для него модель (viewmodel GridItem).
В слое BL, добавлю метод вроде List<GridItem> GetMyItems(bool isActive).

Как предлагаешь это реализовать?

от эменно, хороший пример! во вью у меня генератор грида, который берёт из модели GridItem набор полей, распределяя их по колонкам. порядок следования, заголовок и описание для колонки берётся из атрибута Display. можно ли фильтровать, оттуда же. можно ли сортировать по полю или нет, к примеру, берётся из кастомного атрибута Sort... ну и так далее.

тянуть всю модель и мапить. в чём проблема-то?

Mapper.Map<IEnumerable<SomeDto>, Collection<SomeViewModel>>(source)

эта сколька ж буков!

Парамон,

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

Парамон1. Дублирование.
SomeDto создан специально для среза, фактически для View, то есть дубль ViewModel. Лишняя сущность.

2. Лишний код.
Маппинг и другие, совершенно ненужные телодвижения.

3. Производительность.
Если тянуть модель целиком. Пинать архитекторов можешь и дальше, пока архитекторы тебя сами не пнут )

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

ПарамонList<GridItem> GetMyItems(bool isActive)

во-первых, за использование List как типа возврата, по рукам!

во-вторых, понятие "Grid" есть только во вью, и то: сегодня грид, а завтра красивая адаптивная плитка. в этом и смысл. BLL по барабану должно быть в каком виде будут отображены данные. он не подстраивается под View.

Парамон,

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

поражаете вы меня

ПарамонДля каждой выборки свой dto? А потом оно мапится в свои копии ака ViewModels?
Вот и представь, что в API сервисе нужно на одно поле меньше, значит в топку твой dto. А завтра в десктоп админке нужно приджойнить еще табличку, и где тут у нас "те же классы бизнес-логики"? Делаем новые, получаем перегруженные библиотеки с неявной ответственностью.

Или может быть, у вас все клиенты модели с идентичной и неизменной логикой? )

даже не смешно. что за детский лепет? какое ещё "на одно поле меньше"? что чушь вообще? как это относится к программированию?

DTO не мапится в "свою копию". оно мапится во ViewModel. и их полная идентичность -- это лишь частный случай, который не даёт право подсовывать DTO вместо ViewModel.

Model >= ViewModel, и не стоит делать "узкие кортежи" ради призрачной производительности. это глупо. выигрыша даже в 10мс вы не получите. ORM умеет офигенно кешировать. если мало, делается агрессивное кеширование там где это требуется. кстати, где это требуется, кортежи не помогут.

короче пппц. страшно представить что вы там накуралесили с такими "идеями".

учите матчасть. не ипайте мозг.