Рекомендации по инструменту доменного моделирования - межпроектные отношения и наследование

Question

Мы ищем инструмент моделирования ORM / Domain, который позволит нам сгенерировать несколько связанных моделей доменов для нескольких проектов / сборок, сгенерированных по принципу «сначала база данных» из нашей базы данных MSSQL. Нам нужна помощь в определении того, какие инструменты будут отвечать нашим потребностям.

Требования:

1. Межпроектные отношения

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

2. Перекрестное наследование проекта

   • Как и выше, мы хотим иметь возможность абстрагировать общие функциональные возможности в базовые классы в одной доменной модели и наследовать их.
   • Примечание. Связи наследования между доменами будут ограничены, только одна или две на поддомен.
   • Примечание: это не должно иметь значения, но мы используем "Table per Type" или " Inheritance Table Class " для моделирования нашего наследования в нашей реляционной (DB) схеме

3. Сгенерированные классы должны быть:

   1. Помечено с атрибутами DataContract / DataMember
   2. Уведомление об изменениях свойств (с помощью реализаций INotifyPropertyChanged)
   3. Имеют частичные методы On * PropertyName * Changed () (например, в соответствии с объектами, созданными в Linq to SQL и Entity Framework)
   4. (Идеально, но не обязательно) Связанные типы коллекций должны реализовывать INotifyCollectionChanged.

Будем благодарны за любые отзывы о любых инструментах ORM, которые поддерживают (или имеют обходные пути для поддержки) эти критерии!

ПРИМЕЧАНИЕ. Инструменты, на которые мы смотрели (но это не исключает их полностью):

• LightSpeed ​​ (прекрасно, но не поддерживает межпроектное наследование легко).
• LLBLGen (сложный и всеохватывающий, но при группировке в режиме AsSeparateProjects кажется, что он не поддерживает кросс-модельные отношения, не говоря уже о наследовании).
• Entity Framework (Я только что заблудился ... История дизайнера, когда разделение домена на несколько моделей было не очень приятно).

Answer 1

Хотя это может звучать как обратное тому, о чем вы просите, я бы, вероятно, посмотрел на EF Code First .Поскольку все это построено на основе POCO, DbSets и класса DbContext, вы сможете довольно легко заставить работать наследование.

Имейте свои общие модели и абстрактный DbContext в общей сборке.Иметь конкретные модели и окончательный DbContext в пользовательских сборках.

На фронте WinForms здесь приведен пример кода для того, чтобы сделать наборы наблюдаемыми.Вы должны позаботиться о INotifyPropertyChanged самостоятельно, но это довольно просто.

Недостаток EF Code Во-первых, вы не сможете просто сгенерировать все классы.При этом они достаточно просты, чтобы написать, что я, вероятно, просто напишу их по мере необходимости, пока вы кодируете остальную часть приложения.Любая форма универсального автоматизированного инструмента будет иметь проблемы с определением, какие модели и свойства являются общими по сравнению с конкретными для клиента.

Answer 2

Это определенно требует небольшого проекта для проверки концепции, потому что ваши требования не являются чем-то, что обычно описывается в статьях об EF., part 2 ) и попробуйте сделать простое решение, которое станет доказательством того, что вы можете использовать как отношения, так и наследование между несколькими EDMX.Шаблон T4 для генерации классов из EDMX - начните с шаблона POCO и измените его функции генерации.