Что является хорошей практикой в ​​проектировании системной архитектуры .NET в отношении нескольких моделей и агрегатов? - PullRequest
2 голосов
/ 12 мая 2010

Я разрабатываю архитектуру более крупного предприятия и сомневаюсь в том, как разделить модели и спроектировать их. Есть несколько моментов, для которых я хотел бы получить предложения: - модели для определения - способ определения модели

В настоящее время моя идея состоит в том, чтобы определить:

  1. Модель ядра (домена)
  2. хранилища для получить данные для этой доменной модели из база данных или другой магазин
  3. Модель бизнес-логики, которая будет содержать бизнес-логика, логика проверки и более конкретные версии форм методы извлечения данных
  4. Просмотр моделей, подготовленных для специально отформатированных вывод данных, которые будут проанализированы виды разного вида (веб, серебряный свет и т. д.).

Для первой модели я озадачен тем, что использовать и как определить режим. Должны ли объекты этой модели содержать коллекции и в какой форме? IList, IEnumerable или IQueryable коллекции? - Я думаю о неизменных коллекциях, которыми является IEnumerable, но я бы хотел избежать огромных коллекций данных и предложить свой уровень бизнес-логики с выражениями LINQ, чтобы деревья запросов выполнялись на уровне данных и извлекали только действительно необходимые данные для ситуаций как тот, когда я извлекаю очень специфическое подмножество элементов среди тысяч или сотен тысяч.

Что если у меня есть предмет с несколькими тысячами заявок? Я не могу просто создать коллекцию IEnumerable из этой модели, а затем получить список элементов в каком-либо методе репозитория или даже методе бизнес-модели. Должно ли это быть IQueryable, чтобы я фактически передавал свои запросы в репозиторий на всем пути от уровня модели бизнес-логики? Должен ли я просто избегать коллекций в моей доменной модели? Должен ли я аннулировать только некоторые коллекции?

Стоит ли разделять модель предметной области и модель BusinessLogic или интегрировать их?

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

Это пример того, что я имел в виду: архитектура рисунок 1 http://img199.imageshack.us/img199/7364/arch1p.jpg

Итак, мои объекты Домена будут выглядеть (например, *)

public class Item
    {
        public string ItemName { get; set; }
        public int Price { get; set; }
        public bool Available { get; set; }
        private IList<Bid> _bids;
        public IQueryable<Bid> Bids
        {
            get { return _bids.AsQueryable(); }
            private set { _bids = value; }
        }
        public AddNewBid(Bid newBid)
        {
            _bids.Add(new Bid {....
        }
    }

Где Bid будет определен как обычный класс.

Репозитории будут определяться как фабрики извлечения данных и использоваться для передачи данных в другую (бизнес-логику) модель, которая снова будет использоваться для передачи данных в ViewModels, которые затем будут отображаться различными потребителями.

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

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

Один из самых важных вопросов - где взять типизированные коллекции IQueryable? - Начиная с репозиториев и заканчивая бизнес-моделями или вовсе не предоставляя доступ к твердым IList и IEnumerable из репозиториев, они работают с более конкретными запросами внутри бизнес-модели, но имеют более точные методы поиска данных в репозиториях.

Итак, что вы думаете? Есть предложения?

1 Ответ

3 голосов
/ 12 мая 2010

Я не думаю, что форсирование такого дизайна в каждом приложении на предприятии - это, в первую очередь, хорошая идея. Это очень специфично. Как вы можете предсказать, какие будут потребности отдельных приложений?

Во-вторых, то, что вы представили, на самом деле не является дизайном, управляемым доменом. Похоже, что n-уровневый подход Microsoft благословил. У вас есть структуры данных на всех трех уровнях. Зачем отделять вашу «модель домена» от бизнес-модели? Богатой модели предметной области, содержащей как данные, так и поведение, должно быть достаточно для большинства сложных систем. Модель представления может быть построена поверх этой модели (простое, классическое решение) или непосредственно из базы данных (решение CQRSish). Последнее, похоже, лучше работает в сложных сценариях.

Вы спрашиваете, что пункт имеет тысячи ставок. Что ж, возможно, bid представляет собой совокупный корень (концепция домена, которого вам не хватает) и не должен содержаться ни в одной коллекции.

Мой совет: если вам нужна модель предметной области, придерживайтесь методов моделирования DDD (Эрик Эванс, Джимми Нильссон) и не следуйте буквально Руководству по App Archi. При необходимости добавьте немного CQRS в свое решение, чтобы очистить модель от проблем, связанных с пользовательским интерфейсом. Таким образом вы избежите всевозможных проблем, связанных с обработкой коллекции.

...