МСУАлексей Кпропущено...
В прошлый раз ты тоже был шокирован тем, что пишет Лёша про слой Expression + IQueryable внутри репозитариев, а теперь тебя от ОДаты за уши не оттащишь.

Я пророк, верь мне!
Опять ты путаешь теплое с мягким :) Репозиторий как и сейчас у меня не отдает никаких IQueryable. Репозиторий - это обвязка над сгенеренным OData клиентом. Ты реально так ничего и не понял? ))ОДата - часть Service Layer сервера приложений. Какая ещё "обвязка"?

МСУАлексей КEF-контекст это DAL в чистом виде, C# обёртка вокруг БД. Модель строится поверх него.
1. EF контекст - это не просто DAL, это полноценная доменная модель http://www.design-pattern.ru/patterns/domain-model.html
2. Эта модель живьём используется в свое бизнес логики.

P.S. Зачем мне строить модель над моделью?Мне так не кажется:
1. Рассматриваю DbContext как DAL, а EF как банальный SQL-генератор.
2. Слой, в котором реализованы LINQ запросы рассматриваю как логику.

зы: С появлением LINQ-2-SQL традиционные design patterns организованными группами идут в лес.

hVosttАлексей КТы сначала ознакомься, потом критикуй.




да в топку такой генератор, я бы послал топ менеджера открытым матом, если бы мне такое УГ навязывали, ты уж извини, но по-другому ЭТО по-другому ну никак язык не поворачивается назвать. качество генерируемого кода ниже плинтуса. нафиг было время на это УГ тратить? какую задачу заказчика это решает? он что заказывал этот унылый генератор не пойму? вот видимо у вас заказов и нет, если вы намерянно раздуваете решения, страдая конкретной чепухой, вместо того что делом заниматься.Ближе к делу, что не так? Если тебе что-то не знакомо, это не значит, что оно не правильно.

МСУАлексей КОДата - часть Service Layer сервера приложений. Какая ещё "обвязка"?
Бизнес ходит к Service Layer только через обвязку, акстись и пой. Ты меня пугаешь всё больше и больше...

Алексей К1. Рассматриваю DbContext как DAL, а EF как банальный SQL-генератор.
2. Слой, в котором реализованы LINQ запросы рассматриваю как логику.
1. Ты недооцениваешь EF. Хотя можешь использовать его хоть как кальсоны в холода. Но можно из него выжать гораздо больше.
2. Логика - это не просто запросы. Какая-то каша у тебя в голове... :)

Алексей Кзы: С появлением LINQ-2-SQL традиционные design patterns организованными группами идут в лес.
Ты о чем?Сто раз это всё уже обсуждали, вот вообще не хочу...

Мне интересно, будет ли конструктивная критика от hVostt.

hVosttАлексей КБлиже к делу, что не так? Если тебе что-то не знакомо, это не значит, что оно не правильно.

нарушение общепринятого стиля кодирования, в том числе того, что для коллекций в нейминге должен всегда применяться pluralize (мн. число для контейнеров, хранящих больше одного экземпляра), при этом класс сущности должен олицетворять одну запись, у тебя же как Бог на душу положит, другими словами по-дебильному,Вертел я эту плюрализацию сам знаешь на чём. Не собираюсь добавлять бардак в проект. Про страдания эстетов писал выше.

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

hVosttда ещё использование entity в качестве dto, и всё это делается, видимо, в угоду mvvm-а. ты в одном месте умудрился сделать попытку подстроиться под БД и под логику клиента. скажать что это Жопа, -- ничего не сказать. это конкретный фейл. так делать в энтерпрайзе нельзя, ни в коем случае. ахтунг короче.Это всё слова, не подкреплённые фактами. Пшик, одним словом...

hVosttАлексей КЧем валидация контекстом не угодила?

кушать надо ложкой, а не сапогом. На уровне БД валидация тоже не нужна? Ну давай делать все поля необязательными.

hVosttАлексей К,

почитай на досуге, достигни уже просветления:

http://www.pluralsight.com/courses/table-of-contents/efarchitecture

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

hVosttКритика конструктивного уровня будет? Пока всё на уровне: "Мне не нравится, мы так не делаем, значит не правильно".

МСУАлексей КСто раз это всё уже обсуждали, вот вообще не хочу...
Ну так и я о том же :)

Алексей КМне интересно, будет ли конструктивная критика от hVostt.
Так вроде ро делу пишет, нет? Пересмотри своё отношение к EF, серьезно :) Ты с ним работаешь как с типизированным датасетом. Непонятно, зачем тебе такая мощь как EF...Ни хрена себе работа с Датасетом. Все бы так с Датасетами работали.

МСУ1. Никаких классов с маленькими буквами.
2. Классы модели должны быть внятными и четкими.
3. Классы модели должны описывать бизнесовую модель, никаких костылей на именования таблиц и вьюх в БД! Инфа 100%, верь мне (с)
4. Никакого дерьма типа SenderPersID_Reference, ты упал чтоле? )) Выпилить и забыть!
5. Никаких реализаций List, это даже не обсуждается. Только абстракция!
6. И хватит уже велосипедов! Возьми готовый инструмент, всё уже написано за тебя.
7. Не спорь! :)Дизайнер и 100+ таблиц == жесть.

А так да, извини, что потревожил твоё тонкое эстетическое восприятие названий в EF контексте.

МСУhVosttпропущено...
да ещё использование entity в качестве dto, и всё это делается, видимо, в угоду mvvm-а.
В MVVM никакие DTO не нужны, всё можно сделать на чистых entities. Ну и всегда по месту для View можно запилить ViewModel, которая в себе содержит несколько чистых entity. Никаких DTO!+100200300

МСУАлексей КВертел я эту плюрализацию сам знаешь на чём. Не собираюсь добавлять бардак в проект. Про страдания эстетов писал выше.
Вон из класса! Сегодня опять двойка. Без плюрализации только канализация Игры разума с плюрализаторами мне ни к чему. Чем проще - тем лучше!

МСУНе поленился ведь.