Я обычно предпочитаю «бизнес-объект инкапсулирует объект данных / хранилище» лучше всего. Тем не менее, вкратце вы можете обнаружить высокую избыточность ваших объектов данных и бизнес-объектов, которая может показаться бесполезной. Это особенно верно, если вы выбираете ORM в качестве основы для уровня доступа к данным (DAL). Но в долгосрочной перспективе реальная отдача - это жизненный цикл приложения. Как показано, нередки случаи, когда «данные» поступают из одной или нескольких подсистем хранения (не ограничиваясь RDBMS), особенно с появлением облачных вычислений, как это обычно происходит в распределенных системах. Например, у вас могут быть некоторые данные, полученные из службы 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;
}
}