skyANA,

да, мы же ведет дискуссию про объекты EF и новые бизнес-объекты. Я вот спросил на примере конкретной БД.

skyANA,

что-то в тупик меня поставили. Я кстати не особый знаток ЕФ,достаточно давно с ним работал. Но если честно не вижу для нашей беседы разницы в тех походах. А про БД Northwind вы загнули она достаточно типичная.

skyANA,

авторА что значит "она достаточно типичная"? типичное решение типичной задачи. Клиенты, продажи и т.д. Да и вообще я всего лишь хотел донести мысль, что следовать принципам потому что так написано где-то имхо глупо и неправильно. Если модели домена и бизнеса совпадают это сразу неправильно и плохо? Бред.

skyANAskyANAВ реляционной БД это минимум две сущности/таблицы (в реальности конечно больше, т.к. есть всякие справочные данные типа валюты, единиц измерения и т.п.), в коде доменной модели одна - заказ (агрегирующая).Тут имеется ввиду, что данные в БД раскиданы по нескольким таблицам, а инстансе заказа они собраны.
а там в EF будет все что нужно в связанной коллекции :). Но если даже предположить что надо получить имя какого-то справочника для заказа, то какой-то код приложения дернет 2 репозитория (например) и заполнит некий объект. Но помойму это не маппинг, а уже совсем логика /контроллер/ хуеллер. Например пусть это будет в методе WCF сервиса СформироватьЗаказ НОМЕР ХХХ

skyANA,

вот видите, вы говорите "глупости", а я вам говорю что это не глупости. Давайте разбираться далее.
Под репозиторием я подразумеваю http://blogs.msdn.com/b/wriju/archive/2013/08/23/using-repository-pattern-in-entity-framework.aspx вот- что-то такое. И вполне может быть что при формировании "заказа" может потребоваться обращаться к нескольким таким репозиториям. В конце концов представим что у нас не EF c готовыми маппингами связанных сущностей а самописный слой. В чем глупость?

skyANAХотя нет. Давайте сразу на Ваш вопрос ответим:netivanВозьмем известный пример бд Northwind. Что там маппить будете?
Маппить (отображать) будем данные из нескольких таблиц БД на одну доменную сущность - заказ. Согласны?
я вам косвенно ответил уже.
авторЗначит есть заказы. В заказе есть шапка/заголовок/основная часть и товары/услуги/детализация.
Имеем заказ как бизнес-сущность, совсем не связанную с БД, так?
Чтобы "собрать" заказ я буду обращаться к разным сущностям Бд через репозиторий EF (например). И вся логика работы с заказом будет в отдельном классе/сервисе/контроллере. Только я бы это маппингом не стал называть ибо вывести Заголовок как вы сказали в виде больших букв,например, задача совсем не репозитория с маппингами :) Если вы намекаете, что тем самым я буду дублировать код например в сервисе и веб-приложении, то да, такое может быть и тогда этот бизнес-объект с логикой будет в отдельном месте, а уже результат его работы будут использоваться все по своему.
ЗЫ наверное пример с большими буквами неудачный, тут сразу закидаете что это "представление". Пусть будет лучше какая-то сложная формула для суммы заказа.
ЗЫ фух, слишком для вечера пятницы!

skyANAnetivan, Вы скачете с пятого на десятое и путаетесь.

Ещё раз сначала:

1. в БД две таблицы: Orders (шапка/заголовок/основная часть заказа) и OrderDetails (товары/услуги/детализация по заказу);
2. с точки зрения доменной модели одна сущность: Order (заказ).

Вам нужно представить данные, что лежат в БД в виде сущности доменной модели (экземпляра класса Order), согласны?

Это называется object-relational mapping. Отображение реляционнных данных на объект области определения.
Бизнес логика работы с заказом нам тут пока на фиг не нужна, код этой логики отрабатывал, когда заказ оформляли (генерировался номер заказа, учитывались всякие скидки/наценки).

Ни про какие выводы Заголовка куда-то там в представление я не писал, и уж тем более не называл это маппингом.
да, я напутал. У меня это будет так OrderRepository<Order>, где Order это класс EF.

skyANA,

не Ура, их несколько. Вот разгребу напишу код).Хотя возможно мы говорим об одном и том же.

skyANA,

мы немного по-разному понимаю данный термин. Хорошо, в конкретном примере "Заказ" будет единственным нужным репозиторием. Вообщем вроде бы мы пришли в завершению темы. Может кто еще выскажется)