Парамон, а как Вы думаете почему вообще разделяют Model и ViewModel?

Например у меня в маленьком проекте одни и те же классы бизнес-логики используются как в десктоп админке, в MVC приложении, в API сервисе для интеграции с внешними системами, так и в сервисе для мобильных клиентов.
То есть части одной и той же доменной модели доступны абсолютно разным представлениям.

Вам оно может быть и не надо сейчас, но подумайте, что если завтра заказчик к сайту захочет ещё и сервис, отдающий JSON его партнёрам, а послезавтра ещё и экспортировать и ипортировать данные в формате XML?

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

На фига вообще DAL, BLL? Из грида сразу в БД, фигли. Всего-то надо SqlDataSource прописать.

А вообще такие вопросы конечно доставляют. Сложно что-ли определение MVC (model-view-controller) хотя бы на Википедии прочитать?

T_STVТак вот в чем вопрос - методы BLL должны использовать классы Model и в контроллере конвертить ViewModel в Model или же стразу ViewModel?Пройдёмся по определениям:ВикипедиЯ - Модель (англ. Model ). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать .
...в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, а вся бизнес-логика , следует отметить о возможности модели инкапсулировать в себе другие модели...

- Модель представления (англ. View Model ) является , с одной стороны, абстракцией Представления , а с другой, предоставляет обёртку данных из Модели, которые подлежат связыванию. То есть, она содержит Модель, которая преобразована к Представлению , а также содержит в себе команды, которыми может пользоваться Представление, чтобы влиять на Модель.
Ответ, думаю, очевиден.

ПарамонskyANAПарамон, а как Вы думаете почему вообще разделяют Model и ViewModel?

Понятие Model зависит от контекста, а ViewModel уже как то связана с View, логично? )Не увиливайте от ответа. Контекст в названии и начале топика определён

ПарамонskyANAНапример у меня в маленьком проекте одни и те же классы бизнес-логики используются как в десктоп админке, в MVC приложении, в API сервисе для интеграции с внешними системами, так и в сервисе для мобильных клиентов.
То есть части одной и той же доменной модели доступны абсолютно разным представлениям.

Вам оно может быть и не надо сейчас, но подумайте, что если завтра заказчик к сайту захочет ещё и сервис, отдающий JSON его партнёрам, а послезавтра ещё и экспортировать и ипортировать данные в формате XML?

Для каждой выборки свой dto?1. У меня в Domain Model нет DTO, а полноценные бизне-объекты.
2. Что есть каждая выборка?

ПарамонА потом оно мапится в свои копии ака ViewModels?Да, это нормальная практика. Даже с примерами в книжках

ПарамонВот и представь, что...Хорошо себе представляю, т.к. продукт развивается вместе с предметной областью и требованиями бизнеса . Не вижу проблем.

P.S.: подумайте над тем, зачем я выделил жирным строчку.

ПарамонskyANAНа фига вообще DAL, BLL? Из грида сразу в БД, фигли. Всего-то надо SqlDataSource прописать.
Вот кстати в ObjectDataSource по идее что передавать нужно? А GridView вообще отлично IQueryable кушает, это нормально?Не могу отвтеить, так как ни разу не пользовался ObjectDataSource и IQueryable в представление не пробрасывал

ПарамонМСУПотребители могут захотеть иметь какую-то свою реализацию. Например, в впф мне нужна такая реализация - отслеживаемая коллекция ObservableCollection<T>. Поэтому, не нужно навязывать реализацию, правильнее отдать низкоуровневую абстракцию в угоду универсальности.
List просто говорит мне, что это уже готовые к употреблению данные.


МСУПарамон, мой репо может юзаться другими платформами, например, впф. Зачем мне в впф твои вью модели с привинченными атрибутами валидации? Ты предлагаешь в впф тянуть референс на мвц?
В принципе валидация менятся не должна. Можно вью модели вынести в отдельню сборку, не суть, мне такой вариант тоже не по вкусу.

Юзать один репо хорошо, в случае если впф и все остальные платформы имеют идентичную логику. На практике такое редко, обычно там покажи больше, здесь это лишнее и тд.
В итоге для каждой платформы разные срезы данных, dto для сервиса это не dto для впф.
Какой тогда профит от одной общей, избыточной библиотеки, если там каждый метод используется один раз?

Ну разве что инкапсуляция )Без конкретики спорить не имеет смысла. О какой предметной области идёт речь?

P.S.: лично я с избыточностью пока не сталкивался. Может потому, что не пытался запихнуть всё в ядро системы?

T_STVhVostt, МСУ, skyANA

А как быть если мне надо достать джоин 2х таблиц Table1 и Table2? как решается эта задача, учитывая что у меня только 2 класса в BLL Table1 и Table2?А что лежит в этих таблицах? Как это связано с бизнес-логикой? Зачем делать джоин?

Очень часто используют Object-Relational Mapping, чтобы из реляционных данных получить бизнес-сущность.

ПарамонskyANA1. У меня в Domain Model нет DTO, а полноценные бизне-объекты.
2. Что есть каждая выборка?
Выборка, это когда мне нужно выбрать только два поля модели из 5 свзязанных таблиц. Такое бывает?Не припомню.

Помню нужно было основную часть данных страницы вытащить из MongoDB, без компонентов и их настроек. А два поля из 5 таблиц. Нет, не было такого.

А как Вы решаете такие задачи? SELECT прям в коде страницы выполняете?

ПарамонskyANAP.S.: подумайте над тем, зачем я выделил жирным строчку. Не знаю, красивое предложение? )Не угадали

ПарамонskyANAНе могу отвтеить, так как ни разу не пользовался ObjectDataSource и IQueryable в представление не пробрасывал
Вот пример )А зачем он мне? Вам же был нужен.

Парамон, и как он используется?

T_STV, ещё раз: как это связано с бизнес-логикой?

То есть пользователь работал себе с "плоскими" данными и тут бац, оказалось, что нагляднее выводить JOIN?

Дайте больше конкретики: что в Table1, что в Table2? Почему на уровне DAL нельзя сделать JOIN и результат представить в виде объекта(ов) предметной области?

T_STV, сразу бы так. А то Table1, Table2.

ИМХО должно быть так:

ПарамонskyANAПарамон, и как он используется?

Передается во view.А как данными заполняется? Напрямую из БД, минуя BLL и DAL?

T_STVмсущкотоже самое, я беру из базы только 2 поля, намаплимаю на свою расширенную модель ProductInfo и отдаю в выхлоп.

public class ProductInfo
{
public Product Product {get;set;}
public Category Category {get;set;}
}

Будут заполнены только ProductInfo.Product.Name и ProductInfo.Category.Name

Можно пример кода как Вы достаёте только нужные поля?За него это ORM делает :)