Я разрабатываю архитектуру более крупного предприятия и сомневаюсь в том, как разделить модели и спроектировать их.
Есть несколько моментов, для которых я хотел бы получить предложения:
- модели для определения
- способ определения модели
В настоящее время моя идея состоит в том, чтобы определить:
- Модель ядра (домена)
- хранилища для
получить данные для этой доменной модели из
база данных или другой магазин
- Модель бизнес-логики, которая будет содержать
бизнес-логика, логика проверки и
более конкретные версии форм
методы извлечения данных
- Просмотр моделей, подготовленных для специально отформатированных
вывод данных, которые будут проанализированы
виды разного вида (веб,
серебряный свет и т. д.).
Для первой модели я озадачен тем, что использовать и как определить режим.
Должны ли объекты этой модели содержать коллекции и в какой форме?
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 из репозиториев, они работают с более конкретными запросами внутри бизнес-модели, но имеют более точные методы поиска данных в репозиториях.
Итак, что вы думаете? Есть предложения?