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

Doc>Вы POCO c DTO не путаете?

У меня DTO объекты находятся в слое бизнесс-логики. А POKO объекты трансформируются в DTO.

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

Z>А я давно уже не выделяю DAL. Считаю, что ORM вроде EF вполне достаточный DAL.

Вообщем, я почти к этому и пришел, с небольшим отличием.
Библиотеку DAL оставляем, но держим в ней только голые POKO объекты без какой-либо бизнес-логики.
Все linq запросы, различные операции с POKO объектами выносим в библиотеку BLL.

Есть небольшая проблема в этой схеме. Поначалу я думал, что слой БЛ не должен ничего знать о EF. То есть код БЛ должен обращаться к слою DAL только через операции с обычными CLR типами без обращения к типам EF. Точно так же как библиотека BLL понятия не имеет о том, кто ее будет использовать (у меня это сервис WCF). Поэтому и был сделан класс Environment.
То есть другими словами имеем такую цепочку связей:

WCF->BLL->DAL->EF

Плюс такой схемы в том, что в слой BLL добавляется только ссылка на библотеку DAL, и не добавляются ссылки на нэймспейсы и сборки из EF.
Если же мы экспортируем из DAL POKO объекты EF, позволяя работать с ними напрямую (позволяя использовать тот же linq, например), то приходится ссылки на EF добавлять не только в библиотеку DAL, но и в BLL. Но я с этим смирился.

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

MC>Во-первых, мне не нравится название класса — Environment.

Вот от него я тоже избавился. Экспортируем все POKO объекты наружу и всего делов. И linq запросы в коде бизнесс-логики выглядят совсем даже неплохо

MC>У меня методы из бизнес-логики могут выглядеть так:
MC> IList<ScheduleUnit> scheduleUnits = ScheduleUnitAccessor.GetUnitsForUpdate(...);

Название класса ScheduleUnitAccessor уже попахивает бизнесс-логикой