Структуры бизнес-единиц/ценностей с поддержкой DbC

Question

То, что, по-моему, я уделяю больше времени при создании своих бизнес-моделей, - это проверка бизнес-объектов и обеспечение целостности объектов сущности и их отношений. Моя мечта о хорошей инфраструктуре объектов/ценностей поможет мне создать многократно используемые объекты/объекты ценности и легко создать ограничения и правила для отношений, как и в случае с db, но поскольку я считаю, что это действительно бизнес-правила, они принадлежат модели и должны быть полностью независимый от базы данных.

Должно быть легко определить, что требуется свойство Name объекта Person, и что свойство Email должно быть обязательным и соответствовать определенному регулярному выражению и что эти правила должны быть легко повторно использованы f.ex. в проверке ввода в моем веб-приложении.

У меня есть абсолютно опыт работы с Linq в sql, и даже несмотря на то, что он, безусловно, хорошо работает с ним, имеет ограничение, не поддерживая объекты ценности и другие. Мой вопрос в том, будет ли структура Entity или NHibernate более уместной или есть другие технологии, которые лучше всего соответствуют моим потребностям?

Answer 1

Был small book I read last year by Steve Sanderson himself, который информировал меня о концепциях DDD. Несмотря на то, что книга была на ASP.NET MVC в качестве предварительного просмотра, он действительно сосредоточился на «М» в MVC как на истинной и чистой модели домена - используя почти 1/2 книгу по подходам к моделированию (что мне очень понравилось). Одна вещь, к которой он обратился, - это использование объектов Value в контексте Aggregate Roots (очевидно). Но он также показал, как использовать Linq для представления объектов, а также для объектов Value.

Дело в том, что он отметил ограничение Linq, что он должен иметь идентификатор для каждого объекта, включая объекты Value. Он признал, что он нарушил подход, основанный на чистой доменной модели; но это был единственный способ заставить его работать с Linq-to-SQL.

Его рабочая задача заключалась в том, чтобы дать вашему объекту Value Identity; но, сделайте эту идентификацию внутренней, чтобы она не экспонировалась вне вашей модели. Это позволит вам связывать и делиться своими объектами с помощью Linq в ваших репозиториях; не подвергая его клиентским слоям - так что это как бы исключительно объекты Value.

Основы Entity Framework Я полагаю, что это одно и то же требование.

C# пример ниже.

public class MyEntity 
{ 
    [Column(IsPrimaryKey = true 
    , IsDbGenerated = true 
    , AutoSync = AutoSync.OnInsert)] 
    public int EntityID { get; set; } 

    [Column(CanBeNull = false)] 
    public string EntityProperty 
    { 
    get 
    { 
     // insert business rules here, if need be 
    } 
    set; 
    } 
} 

public class MyValueObjectForMyEntity 
{ 
    // make your identity internal 
    [Column(IsPrimaryKey = true 
    , IsDbGenerated = true 
    , AutoSync = AutoSync.OnInsert)] 
    internal int ValueObjectID { get; set; } 

    // everything else public 
    [Column(CanBeNull = false)] 
    public string MyProperty { get; set; } 
} 

Answer 2

Несмотря на то, что кажется ты на стороне .Net мира, я очень рекомендую книгу Эрика Эванса „Domain Driven Design“. (На самом деле больше UML, чем Java, и идеи должны порты.)

Это книга шаблонов, но он предлагает несколько стратегий дизайна, которые утверждают, что все логические правила объектов («инварианты») объединяются в централизованную домен; он затем переходит к риффу по ряду общепринятых шаблонов и делает проблемы, подобные вашим, кажутся более доступными. Ну, если не сговорчивый, по крайней мере более управляемый в долгосрочной перспективе.