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

LD>Рассматриваю 2 варианта:

Расскажите пожалуйста, что с вашей точки зрения даёт любой из этих двух вариантов по сравнению с прямыми обращениями к DbContext? Субъективно я вижу абстракцию ради абстракции.

Здравствуйте, Аноним, Вы писали:

А>В чем же правильность, потом окажется что EF использовать нельзя ( например перехали на Oracle, а там он толком работает ).

Значит надо переехать на linq2sql, bltoolkit.

А>Нужно будет для Oralce быстренько накидать на обычных DataReader, так взял и подменил DAL, а в вашем случае из бизнес-логики придется выкорчевывать хвосты EF.

Взял и подменил DAL звучит очень оптимистично. Надо еще учесть все затраты на этот DAL, когда для того, чтобы сделать один простой запрос в базу приходится городить огород в нескольких файлах. Изменить или повторно использовать такой запрос та еще песня.

По факту оказывается, что один выкорчевать хвосты EF куда проще, чем писать сразу в расчете на такое выкорчевывание. А если учесть, что риск переезда на Oracle для большинства приложений стремится к нулю, то я вообще никаких плюсов не вижу.

Здравствуйте, <Аноним>, Вы писали:

А>В чем же правильность, потом окажется что EF использовать нельзя ( например перехали на Oracle, а там он толком работает ).

Нужно использовать правильные ORM. Например, в случае linq2db переход на Oracle будет заключатся в изменении connectionString в app.config. Ну и базу, конечно, придётся пересоздать.

Здравствуйте, Аноним, Вы писали:

LD>>>Я правильно понимаю, что имеет смысел выкинуть DAL, и использовать EF напрямую?

Z>>Правильно. Продвинутые ORM это и есть DAL.

А>В чем же правильность, потом окажется что EF использовать нельзя ( например перехали на Oracle, а там он толком работает ).
А>Нужно будет для Oralce быстренько накидать на обычных DataReader, так взял и подменил DAL, а в вашем случае из бизнес-логики придется выкорчевывать хвосты EF.

Расскажите — часто у вас такое бывает?

Здравствуйте, Аноним, Вы писали:

А>ОРМ это тоже ДАЛ, но лучше все же абстрагироваться от конкретного ОРМа за своим уровнем абстракции — ДАЛом.
А>Так правильнее.

Чем?

Добрый день!

Возник вопрос, как лучше организовать DAL (Data access layer). Речь идет не о бизнес-логике, а именно об уровне доступа к данным.
Пусть у нас есть следующие объекты:
1. Компьютер. У него есть ID, имя и список пользователей.
2. Пользователь. У него есть ID и имя.

Рассматриваю 2 варианта:

interface IDB : IDisposable
{
  public IComputersCollection Computers {get;}
  void Commit();
}

interface IComputersCollection 
{
  IComputer Create();
  void Add(IComputer);
  void Remove(Guid);
  IComputer Get(Guid);
  IEnumerable<IComputer> GetAll();
}

interface IComputer
{
  Guid Id {get;}
  string Name {get;set;}
  IUsersCollection Users {get;}
]

interface IUsersCollection
{
  IUser Create();
  void Add(IUser);
  void Remove(Guid);
  IUserGet(Guid);
  IEnumerable<IUser> GetAll();
}

interface IUser
{
  Guid Id {get;}
  string Name {get;set;}
  IComputer Computer { get;}
}

Т.е., в этом случае DAL повторяет не структуру базы, а структуру предметной области.

2. 
interface IDB : IDisposable
{
  public IComputersCollection Computers {get;}
  public IUsersCollection Users {get;}
  public IUserToComputerCollection UsersToComputers {get;}
  void Commit();
}

interface IComputersCollection 
{
  IComputer Create();
  void Add(IComputer);
  void Remove(Guid);
  IComputer Get(Guid);
  IEnumerable<IComputer> GetAll();
}

interface IComputer
{
  Guid Id {get;}
  string Name {get;set;}
]

interface IUsersCollection
{
  IUser Create();
  void Add(IUser);
  void Remove(Guid);
  IUserGet(Guid);
  IEnumerable<IUser> GetAll();
}

interface IUser
{
  Guid Id {get;}
  string Name {get;set;}
}


interface IUserToComputerCollection 
{
  IUserToComputer Create();
  void Add(IUserToComputer );
  void Remove(Guid);
  IUserToComputer Get(Guid);
  IEnumerable<IUserToComputer > GetAll();
}

interface IUserToComputer
{
  Guid Id {get;}
  Guid UserId {get;set;}
  Guid ComputerId {get;set;}
}

Т.е. в этом случае DAL повторяет структуру базы.

Естественно, поверх DAL будет бизнес логика. И она будет предоставлять интерфейсы из варианта 1. Но вот как организовать DAL?

Заранее спасибо.

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

A>Здравствуйте, Lonely Dog, Вы писали:

LD>>Рассматриваю 2 варианта:

A>Расскажите пожалуйста, что с вашей точки зрения даёт любой из этих двух вариантов по сравнению с прямыми обращениями к DbContext? Субъективно я вижу абстракцию ради абстракции.
Хороший вопрос. Прочитал несколько статей, там высказывается такая же точка зрения, что и у вас (о том, что это все не нужно).
У меня мотивация была очень простая. Я плохо знаю EF, C# и вообще, весь .NET . Поэтому я хотел вынести код, работающий с EF в отдельную сборку с удобными интерфейсами (без LINQ, лямбд и пр). Отладить ее, написать тесты и потом использовать везде, где мне нужно.
Я правильно понимаю, что имеет смысел выкинуть DAL, и использовать EF напрямую?

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

LD>Хороший вопрос. Прочитал несколько статей, там высказывается такая же точка зрения, что и у вас (о том, что это все не нужно).

DAL нужен когда код доступа к БД имеет хоть какую-то сложность. Эта сложность и убирается в DAL, чтобы не мешать читать BL.

LD>У меня мотивация была очень простая. Я плохо знаю EF, C# и вообще, весь .NET . Поэтому я хотел вынести код, работающий с EF в отдельную сборку с удобными интерфейсами (без LINQ, лямбд и пр). Отладить ее, написать тесты и потом использовать везде, где мне нужно.

Это дело поправимое. Все равно изучить придется, в потом этот код будет только мешать. Тесты тут совершенно не нужны, как и с какой целью тестировать метод User Get(Guid id)?

LD>Я правильно понимаю, что имеет смысел выкинуть DAL, и использовать EF напрямую?

Правильно. Продвинутые ORM это и есть DAL.

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

LD>Рассматриваю 2 варианта:
LD>DAL повторяет не структуру базы, а структуру предметной области.
LD>DAL повторяет структуру базы.

А смысл городить DAL во втором случае? IMHO его задача как раз абстрагировать BL от базы и позволить BL работать в своих терминах и со своими объектами.

LD>>Я правильно понимаю, что имеет смысел выкинуть DAL, и использовать EF напрямую?

Z>Правильно. Продвинутые ORM это и есть DAL.

В чем же правильность, потом окажется что EF использовать нельзя ( например перехали на Oracle, а там он толком работает ).
Нужно будет для Oralce быстренько накидать на обычных DataReader, так взял и подменил DAL, а в вашем случае из бизнес-логики придется выкорчевывать хвосты EF.

Здравствуйте, Аноним, Вы писали:

А>В чем же правильность, потом окажется что EF использовать нельзя ( например перехали на Oracle, а там он толком работает ).
А>Нужно будет для Oralce быстренько накидать на обычных DataReader, так взял и подменил DAL, а в вашем случае из бизнес-логики придется выкорчевывать хвосты EF.
Ну вот если честно, это вторая причина, почему я хотел сделать DAL. Ну точнее, почему я привык его делать. С другой стороны, у меня проект на SQL CE, и вряд ли я перейду на Oracle (масштабы не те, т.к. SQL используется практически для хранения конфигурации).

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

LD>Здравствуйте, Аноним, Вы писали:

А>>В чем же правильность, потом окажется что EF использовать нельзя ( например перехали на Oracle, а там он толком работает ).
А>>Нужно будет для Oralce быстренько накидать на обычных DataReader, так взял и подменил DAL, а в вашем случае из бизнес-логики придется выкорчевывать хвосты EF.
LD>Ну вот если честно, это вторая причина, почему я хотел сделать DAL. Ну точнее, почему я привык его делать. С другой стороны, у меня проект на SQL CE, и вряд ли я перейду на Oracle (масштабы не те, т.к. SQL используется практически для хранения конфигурации).

Субъективно — не решайте проблему, которой у вас нет. Presentation Layer будет у вас? Тоже станете абстрагировать на случай перехода с веба на десктоп?

LD>Хороший вопрос. Прочитал несколько статей, там высказывается такая же точка зрения, что и у вас (о том, что это все не нужно).
LD>У меня мотивация была очень простая. Я плохо знаю EF, C# и вообще, весь .NET . Поэтому я хотел вынести код, работающий с EF в отдельную сборку с удобными интерфейсами (без LINQ, лямбд и пр). Отладить ее, написать тесты и потом использовать везде, где мне нужно.
LD>Я правильно понимаю, что имеет смысел выкинуть DAL, и использовать EF напрямую?

Через абстракцию удобней тестировать и, если все сделать правильно, то тесты с заглушками репозиториев будут вполне адекватны тестам с бд,т.е. выбор зависит от ситуации.

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

LD>Т.е. в этом случае DAL повторяет структуру базы.

LD>Естественно, поверх DAL будет бизнес логика. И она будет предоставлять интерфейсы из варианта 1. Но вот как организовать DAL?

если целью обращаться к DAL через интерфейсы будет только тестирование или структурирование кода, то проще сделать 1 большой интерфейс вместо нескольких как тут а DAL реализацию разнести по partial классам — по 1 на каждую предметную область, чтобы кол-во строк в DAL не зашкаливало за 10000. можно и на несколько интерфейсов разнести если планируется что какаято часть DAL например может переехать в xml файлы или Azure table services, хотя этот редко бывает. DAL выполняет только функции dataaccess, над ним можно еще один сервис повесить который будет выполнять дополнительную бизнес-логику не уложившуюся в БД, в том числе кэширование, security access checks и другое

о вкусе цианистого калия могут судить только те кто его пробовал

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

LD>Добрый день!

LD>Возник вопрос, как лучше организовать DAL (Data access layer). Речь идет не о бизнес-логике, а именно об уровне доступа к данным.
LD>Пусть у нас есть следующие объекты:
LD>1. Компьютер. У него есть ID, имя и список пользователей.
LD>2. Пользователь. У него есть ID и имя.



Я бы советовал познакомиться с паттернами DDD — Repository & Unit of work.
Гораздо более красивые DALы получаются.

ОРМ это тоже ДАЛ, но лучше все же абстрагироваться от конкретного ОРМа за своим уровнем абстракции — ДАЛом.
Так правильнее.

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

IT>Здравствуйте, Аноним, Вы писали:

А>>ОРМ это тоже ДАЛ, но лучше все же абстрагироваться от конкретного ОРМа за своим уровнем абстракции — ДАЛом.
А>>Так правильнее.

IT>Чем?

Low-coupling

Пробовали когда-нибудь поменять ОРМ уже в процессе разработки?
Абстрагирование позволяет это сделать.
Другое дело, что так писать дороже и дольше, но правильнее

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

А>>>ОРМ это тоже ДАЛ, но лучше все же абстрагироваться от конкретного ОРМа за своим уровнем абстракции — ДАЛом.
А>>>Так правильнее.

IT>>Чем?

S>Low-coupling
У любого принципа есть область применения. И у этого тоже.

S>Пробовали когда-нибудь поменять ОРМ уже в процессе разработки?
S>Абстрагирование позволяет это сделать.
Не пробовал. Зачем?
С другой стороны я "пробовал" менять нереляционную базу на реляционную. И довольно успешно.

S>Другое дело, что так писать дороже и дольше, но правильнее
Начинаем сначала: Чем?

СУВ, Aikin

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

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

IT>>Здравствуйте, Аноним, Вы писали:

А>>>ОРМ это тоже ДАЛ, но лучше все же абстрагироваться от конкретного ОРМа за своим уровнем абстракции — ДАЛом.
А>>>Так правильнее.

IT>>Чем?

S>Low-coupling

S>Пробовали когда-нибудь поменять ОРМ уже в процессе разработки?

Уже который раз спрашиваю на форуме, может быть вы ответите — часто у вас такое бывает?

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

А>>>Так правильнее.
IT>>Чем?
S>Low-coupling

Может как раз совсем наоборот?

S>Пробовали когда-нибудь поменять ОРМ уже в процессе разработки?

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

S>Абстрагирование позволяет это сделать.

Позволяет это сделать дороже и дольше.

S>Другое дело, что так писать дороже и дольше, но правильнее

Странная логика: дороже и дольше, но правильнее. Это примерно как "у меня зарплата маленькая, но хорошая".

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

S>Low-coupling
S>Пробовали когда-нибудь поменять ОРМ уже в процессе разработки?
Да. Более того — применять с разу два. EF и BLT. Часть кода там — часть там.

S>Абстрагирование позволяет это сделать.
Что сделать? Сменить ОРМ? Нет, не позволяет. Есть код использующий один ОРМ — есть трансформация который его превратит в код работающий с другим ОРМ. Так вот эта трансформация может быть получена только человеком путём набития шишек. Абстрагирование тут вообще как-бы не про то.

S>Другое дело, что так писать дороже и дольше, но правильнее
Есть у меня хорошо знакомый проект, тесно связан с ним — в нём есть такие абстракции (т.е. возможность подменять слои доступа mssql/etc).
Так вот — одна есть проблема — "переписать" существующую БД со всеми ХП, ну... самая оптимистичная оценка — 3 года работы. Но даже если дать бесконечное время программистам — работа 100% не будет никогда завершена, легче будет написать новую.

А>>>ОРМ это тоже ДАЛ, но лучше все же абстрагироваться от конкретного ОРМа за своим уровнем абстракции — ДАЛом.
А>>>Так правильнее.
IT>>Чем?
S>Low-coupling
S>Пробовали когда-нибудь поменять ОРМ уже в процессе разработки?
S>Абстрагирование позволяет это сделать.
S>Другое дело, что так писать дороже и дольше, но правильнее

Допустим, что DAL совмещен с бизнес логикой.
Если Вам нужно реализовать процедурный DAL (напр. Web service) для тонкого клиента,
то применение ORM в реализации такого DAL может дать выгоду.

Если клиент толстый, то я считаю нужно использовать ORM напрямую.
ORM в этом случае выступает, как объектно ориентированный DAL, не совмещенный с бизнес логикой.
А бизнес логика объектно-ориентированная и выполняется на толстом клиенте.
В случае толстого клиента оборачивать ORM в процедурный DAL будет дороже и вряд ли даст выгоду.
Говорят, что любую проблему можно решить дополнительным уровнем абстракции.
Какая проблема решается в этом случае непонятно.

А правильно всегда то что дешевле (в краткосрочной + долгосрочной перспективе)