hVosttКак считаете, на сколько оправдано выделять Entity-модель (POCO-классы) в отдельную сборку без зависимости от EF?Всё как всегда, сначала предлагается инновация, потом начинаются мысли "а зачем?" :-)
hVosttТ.е. максимально минимизировать эту зависимость, не до 0 конечно, атрибутов из System.ComponentModel.* хватает для описания, а чего не хватает описывается кастомными атрибутами.Fluent API ?
hVosttЯ в последнее время придерживаюсь этого подхода и пока подвоных камней не встретил. Хорошо для тестирования (в разы),Проще/лучше тестовую БД подсунуть? Там и тестовые данные могут быть, и сохранение данных в транзакции с отменой можно протестировать.
hVosttхорошо для возможности «съехать» с монатками от EF на какой-нибудь другой ORM при необходимостиВряд ли удастся сделать кросс-ОРМ-ные LINQ2SQL запросы.
hVostt... чистота.Субъективно.

hVosttData Logic — реализация бизнес-логики, зависит от Data, но не от Data Access.Отделение логики от слоя, содержащего LINQ2SQL запросы, неминуемо приведёт к "N+1 запрос", со всеми вытекающими.

hVosttАлексей КFluent API ?

соглашения лучше, чем Fluent API. тебе же нравится декларативность Knockout? может ну её к лешему, лучше jQuery API? Fluent API не требует навешивания атрибутов, которые обычно специфичны для используемой ОРМ. Поэтому в твоих начинаниях Fluent API может быть полезен. Но я не настаиваю, просто предложил. :-)

hVosttАлексей КПроще/лучше тестовую БД подсунуть? Там и тестовые данные могут быть, и сохранение данных в транзакции с отменой можно протестировать.

для тестов как раз требуется тестить чисто логику, без БД. затем можно и с БД потестить. никто не мешает. в этом вся прелесть, в гибкости.Я не знаю как там у вас, у нас львиная доля логики выполняется в сгенерированном EF-ом SQL. Благодаря этому имеем максимальную производительность решения. Я не представляю выполнение логики без СУБД, хоть она и расположена в СП.

hVosttАлексей КВряд ли удастся сделать кросс-ОРМ-ные LINQ2SQL запросы.
а зачем они? все запросы в слое доступа к данным. какие хочешь. хоть прямые SQL в базу, да хоть через ассемблер прям в кишки системы. но через слой доступа. за его пределами никто ниче про ни про какие SQL не знает, да и знать не хочет.Нынче львиная доля логики выполнена в виде LINQ2SQL. Что поделать, тренд такой, и я с ним согласен. :-)

hVosttАлексей КСубъективно.

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

Но я понимаю, что у всех своя специфика, возможно в твоём случае "N+1" на производительности существенно не сказывается.

hVosttАлексей КОтделение логики от слоя, содержащего LINQ2SQL запросы, неминуемо приведёт к "N+1 запрос", со всеми вытекающими.

в смысле? что за N+1
Не знаю как у вас, в моём случае вынос логики из LINQ-запросов приведёт к следующему:


В простонародье это называется "N+1 query".

skyANAАлексей Кпропущено...

Не знаю как у вас, в моём случае вынос логики из LINQ-запросов приведёт к следующему:


В простонародье это называется "N+1 query".Парадокс однако.Что за парадокс?

МСУhVosttТаким образом можно тестировать всё по отдельности. Для тестов не надо вообще создавать никаких EF-контекстов, и даже знать об их существовании, достаточно мокать репозитории.
Так для тестов и так не надо никаких EF контекстов, мокай репо и всё. Внутри репо - black box. Зачем тебе еще саму EDM модель абстрагировать?

hVosttСпрашиваю, потому что интересно, на какие грабли мне ещё не довелось наступить, хотелось бы глубже разобраться.
Не вижу необходимости тестировать EF контекст и её слой. Там тестировать нечего, логики там ровным счетом ноль.Ещё один архитектор-теоретег.

Как же ты собрался мутить OData, если у тебя нет логики в LINQ2SQL ?

МСУАлексей ККак же ты собрался мутить OData, если у тебя нет логики в LINQ2SQL ?
Не путай тёплое с мягким, практег В OData на сервере - целая инфраструктура контроллеров, функций, экшенов, рутов, маппингов и прочего добра. Это полноценный сервис. Каким боком тут L2S и EF? Ты укурен? Ну логично ОДату делать тупо на базе IQueryable от EF. Не? :-)

МСУАлексей КНу логично ОДату делать тупо на базе IQueryable от EF. Не? :-)
Не "ОДату делать", а " модель ОДаты делать" от EF.Ну назови это так, я не против.
МСУОДата - это не EF, практег :)
МСУВ ОДате модель абстрактна, то есть в эту IEdmModel можно воткнуть не только EF.Я не про "можно", а про "проще".

МСУАлексей К, короче, любитель поклевать моск, в чем вопрос? Кто виноват?

hVosttАлексей КFluent API не требует навешивания атрибутов, которые обычно специфичны для используемой ОРМ. Поэтому в твоих начинаниях Fluent API может быть полезен. Но я не настаиваю, просто предложил. :-)

Дак я же сразу сказал, что атрибутов из ComponentModel.* хватает, а они к EF прямого отношения не имеют.Перспективные ОРМ, на которые ты в будущем захочешь перейти, могут не уметь с ними работать.
hVosttА если чего не хватает, то кастомные атрибуты + соглашения, которые при любом раскладе лучшу Fluent.В любом случае, я бы рассматривал Fluent как запасной вариант.
hVosttАлексей КЯ не знаю как там у вас, у нас львиная доля логики выполняется в сгенерированном EF-ом SQL. Благодаря этому имеем максимальную производительность решения. Я не представляю выполнение логики без СУБД, хоть она и расположена в СП.

Ну так у тебя есть слой доступа к данным. Делай там свой SQL, мы делаем когда потребуется. Например, понадобилось FTS на СУБД, пжалста. Просто в Entity-модели, знать об этих деталях совершенно ни к чему.Я не про SQL, я про LINQ. Например, может потребоваться использовать DbFunctions, специфичный для EF. Например, EF умеет выполнять LINQ запросы, возвращающие вложенные коллекции, а BLToolkit не умеет. Например, EF умеет транслировать в SQL DateTime.Now, а какой-нибудь другой ОРМ может этого не уметь. Примеров можно привести много.

Считаю, что всё, что использует IQueryable, жёстко прибито к EF, надо смириться с этим.

hVosttАлексей КМне производительность важнее. Строю архитектуру в первую очередь исходя из неё.

Но я понимаю, что у всех своя специфика, возможно в твоём случае "N+1" на производительности существенно не сказывается.

Просто не вижу как это влияет на производительность. Говорю же в слое доступа можешь делать что угодно, хоть ядро ОС ковырять.Так и делаем. Только в результате большая часть логики располагается в слое доступа, следовательно тестировать в других слоях просто нечего, логики в них нет или мало. В сложившейся ситуации самым разумным считаю использовать тестовую БД, что сразу и было предложено. :-)

hVosttАлексей КВ простонародье это называется "N+1 query".

а, понял о чём ты. ну дак не вижу проблемы получить всё одним запросом, чистым LINQ.В единичных случаях можно. Проблемы возникают при повторном использовании.

hVosttАлексей КПерспективные ОРМ, на которые ты в будущем захочешь перейти, могут не уметь с ними работать.

Поймут, не пегеживай! Оптимизм - это хорошо. :-)
hVosttАлексей КЯ не про SQL, я про LINQ. Например, может потребоваться использовать DbFunctions, специфичный для EF. Например, EF умеет выполнять LINQ запросы, возвращающие вложенные коллекции, а BLToolkit не умеет. Например, EF умеет транслировать в SQL DateTime.Now, а какой-нибудь другой ОРМ может этого не уметь. Примеров можно привести много.

Считаю, что всё, что использует IQueryable, жёстко прибито к EF, надо смириться с этим.

Вот не согласен. Давече пришлось работать с одной либой, которая решительно не жуёт DateTimeOffset в LINQ. Что делать? Простенький адаптер, и зажувала как миленькая Повезло. Попробуй написать какой-нибудь адаптер для EF, преобразующий Expression Tree - хрентатам. Проще, чем писать LINQ-провайдер-обёртку на сегодняшний день решения нет.

hVosttАлексей КТак и делаем. Только в результате большая часть логики располагается в слое доступа, следовательно тестировать в других слоях просто нечего, логики в них нет или мало. В сложившейся ситуации самым разумным считаю использовать тестовую БД, что сразу и было предложено. :-)

У тя бизнес-логика крепится к СУБД как рыба-прилипала? Это обосновано?Ну это смотря с какой стороны посмотреть. Я бы сказал, что логика в моём случае жёстко крепится к EF. А провайдеры разных СУБД под EF6 худо-бедно стали появляться. А EF7 сразу позиционируется как мультиСУБДный.

hVosttАлексей КПовезло. Попробуй написать какой-нибудь адаптер для EF, преобразующий Expression Tree - хрентатам. Проще, чем писать LINQ-провайдер-обёртку на сегодняшний день решения нет.

Ну нет в мире идеала.. Хотя нет, LINQ всё-таки к нему очень близок. При желании ET можно ковырять, это может быть сложно, но возможно. Ну а реализовывать LINQ провайдер никто не заставляет, нет же необходимости.Я не поленился, написал провайдер-обёртку. Теперь имею подставляемые выражения, как в LINQKit и BLToolkit, описание и реализация есть у меня на сайте, если интересно. Есть идея написать аналог SQL-ного case-when-then, но руки не доходят. В любом случае, полный контроль над Expression Tree радует. :-)

hVosttАлексей КНу это смотря с какой стороны посмотреть. Я бы сказал, что логика в моём случае жёстко крепится к EF. А провайдеры разных СУБД под EF6 худо-бедно стали появляться. А EF7 сразу позиционируется как мультиСУБДный.

А смысло в этом закреплении есть? Неужели всё в производительность упирается? LINQ2EF достаточно быстр же?Ну мы на EF строим в том числе и достаточно сложные отчёты. На этих задачах много мелких SQL-запросов сильно осложняют ситуацию, несмотря на то, что EF на сегодняшний день оптимизирован достаточно хорошо.

В предыдущих десктопных проектах не было пэйджинга, этот факт так же осложняет ситуацию. В новых веб-проектах пэйджинг есть, возможно в них вреда от "N+1" будет меньше.

hVosttАлексей КЯ не поленился, написал провайдер-обёртку. Теперь имею подставляемые выражения, как в LINQKit и BLToolkit, описание и реализация есть у меня на сайте, если интересно. Есть идея написать аналог SQL-ного case-when-then, но руки не доходят. В любом случае, полный контроль над Expression Tree радует. :-)

Ето да. А что BLTookite ещё жыф? Как так?Давно на него не смотрел. Слышал, что они сделали Linq2Db.

hVosttАлексей КНу мы на EF строим в том числе и достаточно сложные отчёты. На этих задачах много мелких SQL-запросов сильно осложняют ситуацию, несмотря на то, что EF на сегодняшний день оптимизирован достаточно хорошо.

В предыдущих десктопных проектах не было пэйджинга, этот факт так же осложняет ситуацию. В новых веб-проектах пэйджинг есть, возможно в них вреда от "N+1" будет меньше.

А вьюхе можно мапить в классы, не пробовали?Используем, когда EF чего-то не может. Например - рекурсивные запросы.

МСУhVosttну я бы не был так категоричен. покрытие 100% часто увеличивает ценник, истино тебе говорю
Логика в поко? Укурен? :)Rich domain model?

МСУАлексей Кпропущено...
Кто виноват?
Путин? Что делать?

МСУhVosttтак дело в том, что ты абстрагируешь слой доступа, а не EDM. что там внутри -- EDM, или NHibernate, или чистый ADO, это уже не важно.
Ну такой и должна быть архитектура.Архитектура прошлого.

МСУАлексей Кпропущено...
Rich domain model?
Упоротость и кретинизм?Да.

МСУАлексей Кпропущено...
Что делать?
Избирать на второй срок? Нет, я за конституционную монархию!

МСУАлексей КДа.
Да.Даа?

МСУАлексей КНет, я за конституционную монархию!
Варианты? А какие тут могут быть варианты?

МСУАлексей КАрхитектура прошлого.
Неожиданно Я всегда говорил, что с появлением LINQ мир сильно изменился.

hVosttАлексей КИспользуем, когда EF чего-то не может. Например - рекурсивные запросы.

Вьюху использую для этого, намапливаю в класс, а дальше обычный LINQ и любые запросы по любому уровню с любым вложением -- и быстро! Ну и я про то же. :-)