Как я могу полностью отделить свой бизнес и слои данных?

Question

В настоящее время я представляю свой бизнес-уровень и уровень данных в одном проекте в своем приложении. У меня очень хорошее разделение проблем между двумя наборами классов. Однако классы My Data Layer принимают в качестве параметров и возвращают мои бизнес-объекты. Так что я буду иметь код, который свободно походит (пожалуйста, не быть слишком критичен этого кода, мой код продукции не выглядит так же, как это):

//business class fragment 
public bool Save() 
{ 
    if(this.IsValid) 
    { 
     //DataProvider is one of many data access classes that implement an IDataProvider interface. Switched elsewhere in the class. This allows switching of Database providers, xml, etc. 
     DataProvider.Save(this); 
     return true; 
    } 
    return false; 
} 

public List<MyBusinessObject> GetObjectsByCriteria(string criteria) 
{ 
    return DataProvider.GetMyBusinessObjectsByCriteria(criteria); 
} 

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

Я много читал о объектах доступа к данным или объектах передачи данных, чтобы решить эту проблему, но это похоже на анти-шаблонный шаблон для этих шаблонов.

Что я могу сделать? Как мне элегантно достичь полного разделения этих двух слоев моего приложения?

Answer 1

Это более общая проблема, чем просто отделить модель домена от доступа к данным. Такая же проблема возникает при попытке отделить логику приложения от модели домена, модели презентации от логики приложения и т. Д.

Общее решение - это метод, называемый Injection Dependency (DI). Некоторые люди также называют это инвертией контроля (IoC).

Основной текст на эту тему был статья Мартина Фаулера Inversion of Control Containers and the Dependency Injection pattern, но с тех пор мы прошли долгий путь, поэтому не забудьте также изучить некоторые более свежие тексты.

Вы можете реализовать DI вручную, например described in this blog post, или вы можете позволить контейнер DI (т.каркас) делают работу за вас.

Common DI контейнера:

• Windsor
• StructureMap
• Spring.NET
• Unity

Answer 2

Извлеките логику устойчивости из своих бизнес-объектов и поместите их в данные Adapter. Это будет похоже на то, как работают существующие адаптеры в .NET (OleDbDataAdapter). Таким образом вы также отделите свои бизнес-объекты и логику персистентности.

Код вашего клиента будет немного более подробным, но я считаю, что это действительно лучший способ по-настоящему разделить слои.

Answer 3

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

В качестве альтернативы шаблону Active Record вы можете изучить проект с поддержкой домена.

Answer 4

Вы должны взглянуть на шаблон DAO (объект доступа к данным). http://en.wikipedia.org/wiki/Data_Access_Object

Лучшим является использование готовой конструкции DAO (подпружиненной). Посмотрите на http://trac.synyx.org/hades

DAO - это не антипаттерн! Используйте их с весной и дженериками, и вам не все равно;)

Существует каждый раз соединение между слоями! Разделить их полностью означает, что у них нет доступа к общению (поэтому они бесполезны).

Используйте основные операции CRUD или динамические искатели, если они имеют смысловой смысл.

Answer 5

Я не думаю, что вы можете иметь два полностью разделены, но вы можете убедитесь, что зависимость не является двунаправленной.

Я думаю, что это важно, чтобы определить несколько вещей:

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

Уровни сохранения, обслуживания и представления информации о объектах модели; модельные объекты не обращая внимания на слой они в

Зависимости для слоев являются однонаправленными и стекать обратно на фронт:.

• persistence-> модель
• сервис-> модель, настойчивость
• view-> модель, сервис

тестовый модуль Вы от задней к передней, так как зависимости позволяют легко насмехаться.

Невозможно иметь НИКАКИЕ зависимости, но вы должны спроектировать их, чтобы не было циклов.

Единственный класс с no зависимостей - это тот, который никто не вызывает и никогда не вызывает другого класса. Это не полезная и не стоящая цель дизайна.

Answer 6

n-level desing: на уровне бизнес-логики вы можете создать класс доступа к данным и класс манипуляции данными. всегда программируйте интерфейс.