skyANAhVostt, конкретные вопросы будут?

У нормальных людей DAL классы - это DAL классы.

что за DAL классы такие у нормальных людей, и какие видятся несостыковки с тем, что написал я?

skyANA,

всё правильно. DAL не светит на ружу Data Context-ом.

пример структуры размещения:

сборка MyProj.Data
— содержит определения классов модели (кот. в тоже время являются DTO)
— ничего не знает о DataContext и Entity Framework
— содержит интерфейс IRepository
— содержит публичный интферейс IXXXService и закрытую (internal) реализацию XXXService
— содержит публичный интерфейс IUnitOfWork

сборка MyProj.Data.Access
— референсит MyProj.Data и EF
— содержит реализацию Data Context
— реализует IRepository из MyProj.Data
— реализует IUnitOfWork


основной проект ссылается на обе сборки. регистрирует их как модули и работает исключительно с интерфейсами через IoC. в следствие этого Data.Access заменить можно (на что угодно, хоть на Redis реализацию), Data — заменить нельзя, так как это суть есть модель.

через IXXXService доступ к бизнес-логике. все операции над моделью XXX и связанными сущностями. через IUnitOfWork получаем доступ к сохранению изменений. если контроллер не владеет IUnitOfWork, он ни при каких обстоятельствах, что бы он не делал, не может произвести никаких изменений с моделью.

какие несостыковки? или вы предлагаете еще один слой классов Модели над DTO, а только затем уже ViewModel ?

skyANA,

просто да, так получается, что классы domain модели являются DTO в EF Code First. и через навигационные свойства можно получить доступ к связанным объектам. и это огромный плюс. если на этом завязываться, то мы поимеем зависимость от такого поведения, которую не-EF может не реализовывать и придется реализовывать кастомно (хотя тот же BLToolkit это умеет из каропки и другие игроки тоже могут). правда, мне не приходилось работая с Code First на горячую менять ORM. базу данных можно легко поменять при наличии провайдера.

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

что здесь плохо? может посоветуете, что можно улучшить?

ViPRosплохо то что все в коде
в коде может быть только то, что создано тобою
что создано богом должно быть расширяемо и интерпретируемо через контексты

я проникся

skyANA,

MyProj.Data совершенно ничего не знает о EF (нет референса), а работаю из проекта я именно с ним.

хотя и Business Objects выглядят примерно вот так:

public class Order
{
...
[MaxLength(Basis.Number)]
public string Number {get;set;}
...
public virtual ICollection<Service> Services { get; set;}
...
}

что какбы намекает :) но прямой взаимосвязи нет, только соглашения (для удобства, но это вовсе не обязательно). конечно из DAL я получаю на самом деле инстанс прокси-класса (заэммиченный наследник Order, реализующий Lazy-навигационные свойства) — это щитается?

monstrU,

да Get, Query, Add, Update, Remove...