Архитектура для бизнес-объекты / слой доступа к базе данных

У Вас может также быть фасад для удержаний от клиента для вызова бизнеса непосредственно. Также это создает общие точки входа к Вашему бизнесу.

Как сказано, Ваш бизнес ничему не должен быть выставлен кроме Вашего DTO и Фасада.

Да. Ваш клиент может иметь дело с DTOs. Это - идеальный способ передать данные через Ваше приложение.

Клиенты никогда не должны иметь дело с объектами хранения непосредственно. Они могут иметь дело с DTO непосредственно, но любой объект, который имеет любую логику для устройства хранения данных, которое не перенесено в Ваш бизнес-объект, не должен называть клиент непосредственно.

Проверьте CSLA.net Rocky Lhotka.

Ну, здесь я, упомянул коллега Greg.

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

Клиентский код может не знать о datastorage, где бизнес-объекты хранятся, но возможно или в случае, если, когда существует только один datastorage, или существует несколько datastorages для того же типа бизнес-объекта (пользователи, сохраненные в локальной базе данных и во внешнем LDAP), но клиент не создает эти бизнес-объекты. С точки зрения системного анализа это означает, что там должен быть бесполезным случаи, в которых существование двух datastorages объектов того же типа может влиять на поток варианта использования.

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

Эта ответственность может быть реализована многочисленными способами: это может быть объект соединения определенного типа для каждого хранения данных; это могут быть segregared методы для вызова для создания новых экземпляров ФИЛИАЛА и т.д.

С уважением,

Michael

CLSA был около долгого времени. Однако мне нравится подход, который обсужден в книге Eric Evans http://dddcommunity.org/

Я обычно предпочитаю «бизнес-объект инкапсулирует объект / хранилище данных». Однако вкратце вы можете обнаружить высокую избыточность ваших объектов данных и бизнес-объектов, которая может показаться нецелесообразной. Это особенно верно, если вы выберете ORM в качестве основы вашего уровня доступа к данным (DAL). Но в долгосрочной перспективе настоящая выгода - это жизненный цикл приложения. Как показано, «данные» нередко поступают из одной или нескольких подсистем хранения (не ограничиваясь РСУБД), особенно с появлением облачных вычислений и, как это часто бывает в распределенных системах. Например, у вас могут быть некоторые данные, которые поступают из службы Restful, другой фрагмент или объект из СУБД, еще один из файла XML, LDAP и т. Д. При таком осознании это подразумевает важность очень хорошей инкапсуляции доступа к данным от бизнеса. Позаботьтесь также о том, какие зависимости вы предоставляете (DI) через свои c-tors и свойства.

Тем не менее, подход, которым я занимался, заключается в том, чтобы поместить «мясо» архитектуры в бизнес-контроллер. Думая о современном доступе к данным больше как о ресурсе, чем о традиционном мышлении, контроллер затем принимает URI или другую форму метаданных, которые могут использоваться, чтобы узнать, какими ресурсами данных он должен управлять для бизнес-объектов. Тогда бизнес-объекты сами НЕ инкапсулируют доступ к данным; скорее контроллер делает. Это делает ваши бизнес-объекты легкими и конкретными и позволяет вашему контроллеру обеспечивать оптимизацию, возможность компоновки, среду транзакций и т. Д.Обратите внимание, что ваш контроллер затем будет «размещать» ваши коллекции бизнес-объектов, как это делают контроллеры многих ORM.

Кроме того, рассмотрите возможность управления бизнес-правилами. Если вы внимательно посмотрите на свой UML (или модель в своей голове, как это делаю я: D), вы заметите, что ваша модель бизнес-правил на самом деле является другой моделью, иногда даже устойчивой (например, если вы используете механизм бизнес-правил) . Я бы подумал о том, чтобы позволить бизнес-контроллеру также фактически управлять вашей подсистемой правил, и позволить вашему бизнес-объекту ссылаться на правила через контроллер. Причина в том, что реализациям правил неизбежно часто требуется выполнять поиск и перекрестную проверку для определения действительности. Часто может потребоваться как поиск гидратированных бизнес-объектов, так и поиск внутренней базы данных. Рассмотрите возможность обнаружения повторяющихся сущностей, например, когда гидратирована только «новая». Предоставив вашим правилам управление бизнес-контроллеру, вы можете делать почти все, что вам нужно, не жертвуя этой красивой чистой абстракцией в своей «модели предметной области».

В псевдокоде:

using(MyConcreteBusinessContext ctx = new MyConcreteBusinessContext("datares://model1?DataSource=myserver;Catalog=mydatabase;Trusted_Connection=True ruleres://someruleresource?type=StaticRules&handler=My.Org.Business.Model.RuleManager")) {

User user = ctx.GetUserById("SZE543");
user.IsLogonActive = false;
ctx.Save();
}

//a business object
class User : BusinessBase {
  public User(BusinessContext ctx) : base(ctx) {}

  public bool Validate() {
    IValidator v = ctx.GetValidator(this);
    return v.Validate();
  }
}

// a validator
class UserValidator : BaseValidator, IValidator {
 User userInstance;
 public UserValidator(User user) {
  userInstance = user;
 }

 public bool Validate() {
   // actual validation code here
   return true;
 }
}