Много где обсуждалось. Но хотелось бы конкретики.

А именно. Чем плоха такая схема:

1. Для сервисов и их данных создаются контракты (interface). Интерфейсы принимают и отдают тоже интерфейсы или примитивные типы. Нужно для простой возоможности тестирования (подмена тех или иных сервисов на тестовую реализацию) и для возможности более простого распараллеливания работы.

2. Уже при реализации интерфейсов создаются классы бизнес-объектов (на основе соответствующих интерфейсов, просто нажимаешь правой кнопочкой implement).

Вопрос: чем плохо эти же классы бизнес-объектов наделить атрибутами разными, в том числе Key, Index, Required и пр. и позволить им сохраняться/восстанавливаться через EF? Какие конкретные минусы?

Стали бы вы делать специальные сущности для EF, которые на 90% совпадают с бизнес-объектами?

Здравствуйте, Shmj, Вы писали:

S>Много где обсуждалось. Но хотелось бы конкретики.

S>А именно. Чем плоха такая схема:

S>1. Для сервисов и их данных создаются контракты (interface). Интерфейсы принимают и отдают тоже интерфейсы или примитивные типы. Нужно для простой возоможности тестирования (подмена тех или иных сервисов на тестовую реализацию) и для возможности более простого распараллеливания работы.

>принимают и отдают тоже интерфейсы

Возможно имеет смысл.

S>2. Уже при реализации интерфейсов создаются классы бизнес-объектов (на основе соответствующих интерфейсов, просто нажимаешь правой кнопочкой implement).

S>Вопрос: чем плохо эти же классы бизнес-объектов наделить атрибутами разными, в том числе Key, Index, Required и пр. и позволить им сохраняться/восстанавливаться через EF? Какие конкретные минусы?

Я бы сначала сделал пару сервисов и только тогда думал что можно упростить и унифицировать. Иначе это потеря времени и денег. Как правило супер пупер универсальный велосипед, на котрый потом пытаются натянуть бизнес логику, в последствии хочется выкинуть или пару раз переписать

S>Стали бы вы делать специальные сущности для EF, которые на 90% совпадают с бизнес-объектами?

Что значит специальные сущности? Code First?
У вас есть база данных, от нее и пляшем. Практика показывает, что лучше не полениться и написать ручками. Все равно стахановские реализации придется править, особенно когда поймете какое EF г-но.

Здравствуйте, Shmj, Вы писали:

S>Вопрос: чем плохо эти же классы бизнес-объектов наделить атрибутами разными, в том числе Key, Index, Required и пр. и позволить им сохраняться/восстанавливаться через EF? Какие конкретные минусы?

Можно использовать Fluent Api

D>Что значит специальные сущности? Code First?
D>У вас есть база данных, от нее и пляшем. Практика показывает, что лучше не полениться и написать ручками. Все равно стахановские реализации придется править, особенно когда поймете какое EF г-но.

Небольшие программы вполне комфортно писать Code First, а таких полно во внутренней автоматизации.

Здравствуйте, Danchik, Вы писали:

S>>Стали бы вы делать специальные сущности для EF, которые на 90% совпадают с бизнес-объектами?

D>Что значит специальные сущности? Code First?

Он самый.

D>У вас есть база данных, от нее и пляшем. Практика показывает, что лучше не полениться и написать ручками. Все равно стахановские реализации придется править, особенно когда поймете какое EF г-но.

А что не г-но?

Здравствуйте, Shmj, Вы писали:

S>Много где обсуждалось. Но хотелось бы конкретики.

S>А именно. Чем плоха такая схема:

S>1. Для сервисов и их данных создаются контракты (interface). Интерфейсы принимают и отдают тоже интерфейсы или примитивные типы. Нужно для простой возоможности тестирования (подмена тех или иных сервисов на тестовую реализацию) и для возможности более простого распараллеливания работы.

S>2. Уже при реализации интерфейсов создаются классы бизнес-объектов (на основе соответствующих интерфейсов, просто нажимаешь правой кнопочкой implement).

S>Вопрос: чем плохо эти же классы бизнес-объектов наделить атрибутами разными, в том числе Key, Index, Required и пр. и позволить им сохраняться/восстанавливаться через EF? Какие конкретные минусы?

S>Стали бы вы делать специальные сущности для EF, которые на 90% совпадают с бизнес-объектами?

Создавать интерфейсы для бизнес-объектов — это как-то перебор. Тестированию они и так не мешают, профита не вижу.
По поводу атрибутов: они всё же больше для слоя доступа к данным относятся, не совсем им место в модели. Где-то приемлемо атрибуты прописать, где-то лучше через FluentAPI задать в контексте, чтобы всё было там, где должно быть.

Здравствуйте, karbofos42, Вы писали:

K>Создавать интерфейсы для бизнес-объектов — это как-то перебор. Тестированию они и так не мешают, профита не вижу.
K>По поводу атрибутов: они всё же больше для слоя доступа к данным относятся, не совсем им место в модели. Где-то приемлемо атрибуты прописать, где-то лучше через FluentAPI задать в контексте, чтобы всё было там, где должно быть.

Так в том то и фишка -- если BO не через интерфейсы -- то получается что атрибуты данных не к месту. А если через интерфейсы -- то реализация конкретная может создавать какие угодно свои атрибуты и вспомогательные поля -- оно никак не нарушает договоренности.

Если не интерфейс -- то получается постоянное копирование из бизнес-объектов в сущености EF и обратно. А нафиг эта лишняя глупая работа?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, karbofos42, Вы писали:

K>>Создавать интерфейсы для бизнес-объектов — это как-то перебор. Тестированию они и так не мешают, профита не вижу.
K>>По поводу атрибутов: они всё же больше для слоя доступа к данным относятся, не совсем им место в модели. Где-то приемлемо атрибуты прописать, где-то лучше через FluentAPI задать в контексте, чтобы всё было там, где должно быть.

S>Так в том то и фишка -- если BO не через интерфейсы -- то получается что атрибуты данных не к месту. А если через интерфейсы -- то реализация конкретная может создавать какие угодно свои атрибуты и вспомогательные поля -- оно никак не нарушает договоренности.

S>Если не интерфейс -- то получается постоянное копирование из бизнес-объектов в сущености EF и обратно. А нафиг эта лишняя глупая работа?

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

Получается, что интерфейсы — это вроде BO, а реализация интерфейсов с проставленными атрибутами — это уже ближе к DAL.
Вместо маппинга между классами BO и классами-сущностей EF получатся классы, которые внутри себя будут маппить свойства и нести двойной функционал — и представление структуры БД для EF и реализация интерфейса BO.
Моё мнение — там где есть реляционная БД + ORM — там всегда будет глупая лишняя работа, т.к. будет натягивание ежа на ужа.

Здравствуйте, Shmj, Вы писали:

S>Стали бы вы делать специальные сущности для EF, которые на 90% совпадают с бизнес-объектами?

Когда-то часто совмещал. Но оказалось, что 90% — цифра весьма временная и с развитием проекта стремится к 09%, что делает такое решение не только безсмысленным, но даже вредным. А не меняется эта цифра только в мёртвых проектах.

Здравствуйте, Shmj, Вы писали:

S>Вопрос: чем плохо эти же классы бизнес-объектов наделить атрибутами разными, в том числе Key, Index, Required и пр. и позволить им сохраняться/восстанавливаться через EF? Какие конкретные минусы?

Для небольшого проекта на скорую руку может и пойдет. Для серьезного — я все же предпочел бы разделить доступ к данным и бизнес логику.
1) Понятнее архитектура проекта
2) Легче сопровождать когда каждая часть проекта занята только своей задачей
3) Легко могут появиться новые типы хранилищ (например NoSQL типа Redis, Azure Table Storage и т. д.). DAL может это легко скрыть от BL (BL вообще не должно волновать где и как хранятся данные)
4) Даже в SQL хранилище структура может отличаться от структуры BL

Здравствуйте, Danchik, Вы писали:

D>У вас есть база данных, от нее и пляшем. Практика показывает, что лучше не полениться и написать ручками. Все равно стахановские реализации придется править, особенно когда поймете какое EF г-но.

Ну так пишите без него IMHO EF решает свою задачу: изначально DAL может использовать EF для доступа (с его помощью быстрее писать чем на чистом SQL, и нет необходимости привлечения SQL профи). Разумеется есть задачи, где сразу видно что нужен SQL (сложные запросы, большие объемы данных).

Далее мониторим где узкое место это запросы EF, и переписываем на SQL. DAL делает все это "прозрачным" для BL. Писать все сразу на SQL — это по сути преждевременная оптимизация. В большинстве случаев, выигрыш будет очень не значительным и не будет стоить затраченных на SQL усилий.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Danchik, Вы писали:

S>>>Стали бы вы делать специальные сущности для EF, которые на 90% совпадают с бизнес-объектами?

D>>Что значит специальные сущности? Code First?

S>Он самый.

Для меня Database First, что ни на есть самое эфективное в продакшине.

D>>У вас есть база данных, от нее и пляшем. Практика показывает, что лучше не полениться и написать ручками. Все равно стахановские реализации придется править, особенно когда поймете какое EF г-но.

S>А что не г-но?

linq2db же тут ты не найдешь Code First ни Change Tracking. Зато эфективность запросов можешь контролировать сам, а скорость маппинга обганяет Dapper.
Не конкретно о вас, но, печально, что в наше время програмисты практически не разбираются в SQL и просят от ORM ну несусветного результата от десятиэтажного linq query

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, Shmj, Вы писали:

S>>Вопрос: чем плохо эти же классы бизнес-объектов наделить атрибутами разными, в том числе Key, Index, Required и пр. и позволить им сохраняться/восстанавливаться через EF? Какие конкретные минусы?

Doc>Для небольшого проекта на скорую руку может и пойдет. Для серьезного — я все же предпочел бы разделить доступ к данным и бизнес логику.
Doc>1) Понятнее архитектура проекта
Doc>2) Легче сопровождать когда каждая часть проекта занята только своей задачей
Doc>3) Легко могут появиться новые типы хранилищ (например NoSQL типа Redis, Azure Table Storage и т. д.). DAL может это легко скрыть от BL (BL вообще не должно волновать где и как хранятся данные)
Doc>4) Даже в SQL хранилище структура может отличаться от структуры BL

И поетому проект становится большим и тормознутым
Я бы так категорично обо всех проектах не говорил. Лишняя абстракция часто мешает чем помогает.

Здравствуйте, Danchik, Вы писали:

D>И поетому проект становится большим и тормознутым

Но проект при этом работает, решает задачи и имеет больший функционал, пока кто-то пишет DAL на SQL с нуля
Да и тормознутым не будет, т.к. что надо — переводится в SQL или вообще в более оптимальное хранилище.

Здравствуйте, Doc, Вы писали:

Doc>Разумеется есть задачи, где сразу видно что нужен SQL (сложные запросы, большие объемы данных).

Про сложные запросы промолчу, это видимо выше всякого понимания. Но чем большие объёмы противоречат LINQ? И какие объёмы считаются большими?

Здравствуйте, IT, Вы писали:

Doc>>Разумеется есть задачи, где сразу видно что нужен SQL (сложные запросы, большие объемы данных).
IT>Про сложные запросы промолчу, это видимо выше всякого понимания. Но чем большие объёмы противоречат LINQ? И какие объёмы считаются большими?

Возможно он это пишет на основе опыта работы с EF. Я не знаю как себя ведёт EF на больших проектах, я с ним только игрался. У нас на проекте linq2db используется с базой в несколько террабайт. Полёт отличный.

Здравствуйте, IT, Вы писали:

IT>Про сложные запросы промолчу, это видимо выше всякого понимания.

Продолжайте писать сложные запросы с логикой на EF. Удачи

IT>Но чем большие объёмы противоречат LINQ? И какие объёмы считаются большими?

Тут согласен с вопросом, т.к. я не корректно выразился. Речь про ситуации, когда надо обработать большие объемы данных, но при этом результатом является некая небольшая сводка/статистика.

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, IT, Вы писали:

IT>>Про сложные запросы промолчу, это видимо выше всякого понимания.

Doc>Продолжайте писать сложные запросы с логикой на EF. Удачи

И это вы автору linq2db написали

IT>>Но чем большие объёмы противоречат LINQ? И какие объёмы считаются большими?

Doc>Тут согласен с вопросом, т.к. я не корректно выразился. Речь про ситуации, когда надо обработать большие объемы данных, но при этом результатом является некая небольшая сводка/статистика.

Сложные SQL прекрасно пишутся на linq2db без голого SQL.
К примеру, самыми сложными я бы их не назвал, но все же: здесь
Были переписал представления Northwind на linq2db для тестирования производительности парсера. Все прошло чудесно.
А здесь можно увидеть как я на "view" сделал join.
Вот и SQL для VwSalesByCategory

-- Northwind SqlServer.2012
DECLARE @year1 Int -- Int32
SET     @year1 = 2015

SELECT
    [c3].[CategoryID],
    [c3].[CategoryName],
    [p2].[ProductName],
    Sum([ode].[c1]) as [c2]
FROM
    [dbo].[Categories] [c3]
        INNER JOIN [dbo].[Products] [p2] ON [c3].[CategoryID] = [p2].[CategoryID]
        INNER JOIN [dbo].[Orders] [o2]
            INNER JOIN (
                SELECT DISTINCT
                    [t2].[OrderID],
                    [t2].[ProductID],
                    [t1].[ProductName] as [ProductName1],
                    [t2].[UnitPrice],
                    [t2].[Quantity],
                    [t2].[Discount],
                    Round(([t2].[UnitPrice] * Convert(Decimal(29,10), [t2].[Quantity])) * (1 - Convert(Decimal(29,10), [t2].[Discount])), 2) as [c1]
                FROM
                    [dbo].[Order Details] [t2]
                        INNER JOIN [dbo].[Products] [t1] ON [t2].[ProductID] = [t1].[ProductID]
            ) [ode] ON [o2].[OrderID] = [ode].[OrderID]
        ON [p2].[ProductID] = [ode].[ProductID]
WHERE
    DatePart(Year, [o2].[OrderDate]) = @year1
GROUP BY
    [c3].[CategoryID],
    [c3].[CategoryName],
    [p2].[ProductName]

И зачем мне теперь SQL, склейка строк, параметры, сложность поддержки?

Здравствуйте, Doc, Вы писали:

IT>>Про сложные запросы промолчу, это видимо выше всякого понимания.
Doc>Продолжайте писать сложные запросы с логикой на EF. Удачи

Мне даже интересно, что же такого в EF неправильного, что в нём не следует писать сложные запросы? Можешь как-то сформулировать проблему?

Здравствуйте, IT, Вы писали:

IT>Мне даже интересно, что же такого в EF неправильного, что в нём не следует писать сложные запросы? Можешь как-то сформулировать проблему?

При использовании так нелюбимого многими паттерна Repository и UnitOfWork можно без боли медленный метод перенести в хранимую процедуру.