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.В единичных случаях можно. Проблемы возникают при повторном использовании.