[Из песочницы] Repository Pattern via CSLA .NET01.11.2016 13:03
Создание систем с низкой связанностью (Low Coupling) между модулями обеспечивает множество преимуществ при разработке ПО. В приложениях, написанных с использованием каркаса CSLA .NET, применение стандартных шаблонов для разрыва зависимостей не всегда может быть очевидно.
В данной статье будет рассмотрен вариант отделения слоя доступа к данным (Data Access Layer, DAL) от слоя бизнес логики (Business Layer) при помощи шаблона Repository и описан наиболее распространенный способ внедрения зависимостей (Depency Injection) в бизнес-объекты CSLA .NET. Используется CSLA версии 4.1.
Пример
Итак, пусть у нас есть корневой бизнес-объект Person. У данного бизнес-объекта есть несколько простых свойств из предметной области, дочерняя коллекция объектов Orders и дочерний объект Address:
//Person.cs
[Serializable]
public sealed partial class Person : BusinessBase {
private Person( ) { }
public static Person NewPerson( ) {
return DataPortal.Create( );
}
public static Person GetPerson( int personId ) {
return DataPortal.Fetch( new SingleCriteria( personId ) );
}
public static void RemovePerson( int personId ) {
DataPortal.Delete( new SingleCriteria( personId ) );
}
private static readonly PropertyInfo IdProperty = RegisterProperty( c => c.Id );
public int Id {
get { return GetProperty( IdProperty ); }
private set { LoadProperty( IdProperty, value ); }
}
public static readonly PropertyInfo FirstNameProperty =
RegisterProperty( c => c.FirstName );
public string FirstName {
get { return GetProperty( FirstNameProperty ); }
set { SetProperty( FirstNameProperty, value ); }
}
public static readonly PropertyInfo SecondNameProperty =
RegisterProperty( c => c.SecondName );
public string SecondName {
get { return GetProperty( SecondNameProperty ); }
set { SetProperty( SecondNameProperty, value ); }
}
public static readonly PropertyInfo AgeProperty = RegisterProperty( c => c.Age );
public int Age {
get { return GetProperty( AgeProperty ); }
set { SetProperty( AgeProperty, value ); }
}
public static readonly PropertyInfo CommentProperty =
RegisterProperty( c => c.Comment );
public string Comment {
get { return GetProperty( CommentProperty ); }
set { SetProperty( CommentProperty, value ); }
}
public static readonly PropertyInfo OrdersProperty =
RegisterProperty( c => c.Orders,
RelationshipTypes.Child | RelationshipTypes.LazyLoad );
public Orders Orders {
get {
if ( !FieldManager.FieldExists( OrdersProperty ) ) {
Orders = Orders.NewOrders( );
}
return GetProperty( OrdersProperty );
}
private set {
LoadProperty( OrdersProperty, value );
OnPropertyChanged( OrdersProperty );
}
}
public static readonly PropertyInfo AddressProperty =
RegisterProperty( c => c.Address,
RelationshipTypes.Child | RelationshipTypes.LazyLoad);
public Address Address {
get {
if ( !FieldManager.FieldExists( AddressProperty ) ) {
Address = Address.NewAddress( );
}
return GetProperty( AddressProperty );
}
private set {
LoadProperty( AddressProperty, value );
OnPropertyChanged( AddressProperty );
}
}
}
Код дочерних классов
//Orders.cs
[Serializable]
public sealed partial class Orders : BusinessListBase {
private Orders( ) { }
public static Orders NewOrders( ) {
return DataPortal.CreateChild( );
}
}
//Order.cs
[Serializable]
public sealed partial class Order : BusinessBase {
private Order( ) { }
public static Order NewOrder( ) {
return DataPortal.CreateChild( );
}
public static readonly PropertyInfo IdProperty = RegisterProperty( c => c.Id );
public int Id {
get { return GetProperty( IdProperty ); }
set { LoadProperty( IdProperty, value ); }
}
public static readonly PropertyInfo DescriptionProperty =
RegisterProperty( c => c.Description );
public string Description {
get { return GetProperty( DescriptionProperty ); }
set { SetProperty( DescriptionProperty, value ); }
}
}
//Address.cs
[Serializable]
public partial class Address : BusinessBase {
private Address( ) { }
public static Address NewAddress( ) {
return DataPortal.CreateChild( );
}
private static readonly PropertyInfo IdProperty = RegisterProperty( c => c.Id );
private int Id {
get { return GetProperty( IdProperty ); }
set { LoadProperty( IdProperty, value ); }
}
public static readonly PropertyInfo FirstAddressProperty =
RegisterProperty( c => c.FirstAddress );
public string FirstAddress {
get { return GetProperty( FirstAddressProperty ); }
set { SetProperty( FirstAddressProperty, value ); }
}
public static readonly PropertyInfo SecondAddressProperty =
RegisterProperty( c => c.SecondAddress );
public string SecondAddress {
get { return GetProperty( SecondAddressProperty ); }
set { SetProperty( SecondAddressProperty, value ); }
}
}
Получившаяся диаграмма классов представлена на рисунке:
Обратите внимание, что бизнес-классы помечены модификатором partial, и весь код доступа к данным перенесен в другие части классов для улучшения читаемости. Давайте теперь рассмотрим код доступа к DAL.
Стандартное взаимодействие с DAL
Сперва обратимся к коду, относящемуся к созданию объекта Person. Как видим, у класса определен единственный конструктор без параметров. За создание и извлечение объекта отвечают фабричные методы, которые обращаются к клиентскому порталу данных CSLA. Клиентский портал данных, в свою очередь, обращается к серверному порталу данных. Последний обращается через рефлексию к закрытым методам DataPortal_Create или DataPortal_Fetch класса Person — для создания или извлечения объекта соответственно:
Для вставки, обновления и удаления объекта Person действует та же схема, но используются методы DataPortal_Insert, DataPortal_Update и DataPortal_DeleteSelf соответственно:
Напомню, что при этом метод Save (инфраструктурный метод CSLA) возвращает фактически новый бизнес-объект, созданный на серверном портале данных, именно поэтому следует обновлять все ссылки на сохраненный объект в клиентском коде (концепция т.н. мобильных бизнес-объектов, Mobile Object Pattern):
Наконец, для форсированного удаления используется метод DataPortal_Delete:
Таким образом, в методах DataPortal_XYZ находится вся логика доступа к данным — не только для создания и извлечения данных, но и для обновления и удаления объекта Person в DAL. В этих методах мы видим специфичную логику, которая обычно используется для доступа к данным: код SQL-запросов, соединение с базой данных, создание транзакций для обновления дочерних объектов и т.д.
//Person.Server.cs
public partial class Person {
public static readonly PropertyInfo
Код доступа к DAL дочерних объектов Person аналогичен, за исключением того, что при обновлении дочерних объектов Person передает порталу данных ссылку на самого себя и экземпляр транзакции ADO .NET, поэтому соответствующие методы DataPortal_XYZ дочерних объектов содержат дополнительные аргументы.
Код дочерних классов:
//Orders.Server.cs
public partial class Orders {
internal static Orders GetOrders( Person person ) {
return DataPortal.FetchChild( person );
}
private void Child_Fetch( Person person ) {
const string query = @"SELECT id
,description
FROM All_orders
WHERE person_id = :p_person_id";
using ( var manager = ConnectionManager.GetManager( "CSLAPROJECT" ) ) {
using ( var command = manager.Connection.CreateCommand( ) ) {
command.CommandType = CommandType.Text;
command.CommandText = query;
command.Parameters.AddWithValue( "p_person_id", person.Id );
using ( var reader =
new SafeDataReader( command.ExecuteReader( CommandBehavior.SingleRow ) ) ) {
RaiseListChangedEvents = false;
while ( reader.Read( ) ) {
Add( Order.GetOrder( reader ) );
}
RaiseListChangedEvents = true;
}
}
}
}
private void Child_Update( Person person, OracleTransaction transaction ) {
base.Child_Update( person, transaction );
}
}
//Order.Server.cs
public partial class Order {
internal static Order GetOrder( SafeDataReader reader ) {
return DataPortal.FetchChild( reader );
}
private void Child_Fetch( SafeDataReader reader ) {
LoadProperty( IdProperty, reader.GetInt32( "id" ) );
LoadProperty( DescriptionProperty, reader.GetString( "description" ) );
}
private void Child_Insert( Person person, OracleTransaction transaction ) {
using ( var manager = ConnectionManager.GetManager( "CSLAPROJECT" ) ) {
using ( var command = manager.Connection.CreateCommand( ) ) {
command.CommandType = CommandType.StoredProcedure;
command.CommandText = "csla_project.add_order";
command.Transaction = transaction;
command.Parameters.AddRange( GetParameters( ) );
command.Parameters.AddWithValue( "person_id", person.Id );
command.ExecuteNonQuery( );
Id = ( int )command.Parameters[ "p_id" ].Value;
}
}
}
private void Child_Update( Person person, OracleTransaction transaction ) {
using ( var manager = ConnectionManager.GetManager( "CSLAPROJECT" ) ) {
using ( var command = manager.Connection.CreateCommand( ) ) {
command.CommandType = CommandType.StoredProcedure;
command.CommandText = "csla_project.edit_order";
command.Transaction = transaction;
command.Parameters.AddRange( GetParameters( ) );
command.Parameters.AddWithValue( "person_id", person.Id );
command.ExecuteNonQuery( );
}
}
}
private void Child_DeleteSelf( Person person, OracleTransaction transaction ) {
using ( var manager = ConnectionManager.GetManager( "CSLAPROJECT" ) ) {
using ( var command = manager.Connection.CreateCommand( ) ) {
command.CommandType = CommandType.StoredProcedure;
command.CommandText = "csla_project.remove_order";
command.Transaction = transaction;
command.Parameters.AddWithValue( "p_person_id", person.Id );
command.Parameters.AddWithValue( "p_order_id", Id );
command.ExecuteNonQuery( );
}
}
}
private OracleParameter[] GetParameters( ) {
return new[] {
new OracleParameter( "p_id", Id ) {Direction = ParameterDirection.InputOutput},
new OracleParameter( "p_description", Description )
};
}
}
//Address.Server.cs
public sealed partial class Address {
internal static Address GetAddress( SafeDataReader reader ) {
return DataPortal.Fetch( reader );
}
private void Child_Fetch( SafeDataReader reader ) {
using ( BypassPropertyChecks ) {
LoadProperty( IdProperty, reader.GetInt32( "address_id" ) );
LoadProperty( FirstAddressProperty, reader.GetString( "first_address" ) );
LoadProperty( SecondAddressProperty, reader.GetString( "second_address" ) );
}
}
private void Child_Insert( Person person, OracleTransaction transaction ) {
using ( var manager = ConnectionManager.GetManager( "CSLAPROJECT" ) ) {
using ( var command = manager.Connection.CreateCommand( ) ) {
command.CommandType = CommandType.StoredProcedure;
command.CommandText = "csla_project.add_address";
command.Parameters.AddRange( GetParameters( ) );
command.Parameters.AddWithValue( "p_person_id", person.Id );
command.Transaction = transaction;
command.ExecuteNonQuery( );
Id = ( int )command.Parameters[ "p_id" ].Value;
}
}
}
private void Child_Update( Person person, OracleTransaction transaction ) {
using ( var manager = ConnectionManager.GetManager( "CSLAPROJECT" ) ) {
using ( var command = manager.Connection.CreateCommand( ) ) {
command.CommandType = CommandType.StoredProcedure;
command.CommandText = "csla_project.edit_address";
command.Parameters.AddRange( GetParameters( ) );
command.Parameters.AddWithValue( "p_person_id", person.Id );
command.Transaction = transaction;
command.ExecuteNonQuery( );
}
}
}
private void Child_DeleteSelf( Person person, OracleTransaction transaction ) {
using ( var manager = ConnectionManager.GetManager( "CSLAPROJECT" ) ) {
using ( var command = manager.Connection.CreateCommand( ) ) {
command.CommandType = CommandType.StoredProcedure;
command.CommandText = "csla_project.remove_address";
command.Parameters.AddWithValue( "p_address_id", Id );
command.Parameters.AddWithValue( "p_person_id", person.Id );
command.Transaction = transaction;
command.ExecuteNonQuery( );
}
}
}
private OracleParameter[] GetParameters( ) {
return new[] {
new OracleParameter( "p_id", Id ) {Direction = ParameterDirection.InputOutput},
new OracleParameter( "p_first_address", FirstAddress ),
new OracleParameter( "p_second_address", SecondAddress )
};
}
}
Repository pattern
Пока что мы видели стандартную реализацию бизнес-объектов CSLA, которую часто можно увидеть в коде многих легаси программ, разработанных при помощи CSLA .NET. Как видно из кода, слой доступа к данным и слой бизнес логики тесно связаны друг с другом. Если мы абстрагируемся от слоя доступа к данным, то избавимся от низкоуровневых деталей в бизнес логике и специфических зависимостей, которые они имеют. Это упростит юнит-тестирование наших бизнес-объектов и позволит менять логику доступа к данным независимо от логики бизнес уровня. Поэтому возникает задача по созданию дополнительного уровня косвенности между бизнес логикой и слоя доступа к данным. К примеру, можно воспользоваться известным шаблоном Repository. Создадим интерфейс с необходимыми методами:
//IPersonRepository.cs
public interface IPersonRepository {
PersonData FindPerson( int id );
void AddPerson( PersonData newPerson, out int newId, out object lastChanged );
void EditPerson( PersonData existingPerson, out object lastChanged );
void RemovePerson( int personId );
}
Класс PersonData — это простой объект передачи данных (DTO, Data Transfer Object):
//PersonData.cs
public sealed class PersonData {
public int Id { get; set; }
public string FirstName { get; set; }
public string SecondName { get; set; }
public int Age { get; set; }
public string Comment { get; set; }
public object LastChanged { get; set; }
}
Для абстрагирования от кода ADO .NET поддержки транзакций создадим простые интерфейсы IContext и ITransaction:
Теперь хотелось бы, чтобы в методах DataPortal_XYZ класса Person вместо специфического DAL кода использовались методы определенных выше интерфейсов. Возникает задача внедрения зависимостей в бизнес-объект Person. Классический способ — протащить зависимости через конструктор Person нельзя из-за ограничений CSLA (использование фабричных методов), поэтому рассмотрим другие возможные способы решить эту задачу.
Setter Method injection
Добавим в класс Person закрытое поле типа IPersonRepository:
Обратите внимание на использование атрибутов [NonSerialized] [NotUndoable] — зависимость IPersonRepository не должна сериализоваться при перемещении объекта Person от одного физического узла к другому (Mobile Object Pattern) и участвовать в многоуровневой отмене CSLA (N-Level Undo).
Вместо метода конфигурации можно использовать свойство PersonRepository (т.н. Property Setter Injection):
[Inject]
[EditorBrowsable( EditorBrowsableState.Never )]
private IPersonRepository PersonRepository {
get { return _personRepository; }
set { _personRepository = value; }
}
Обратите внимание, что в нашем случае свойство PersonRepository будет использоваться только на серверной стороне портала данных, поэтому его можно скрыть от Intellisence с помощью атрибута EditorBrowsable.
В общем случае внедрить зависимости в уже созданный инфраструктурой CSLA бизнес-объект можно, воспользовавшись следующими якорями абстрактного класса BusinessBase: DataPortal_OnDataPortalInvoke, Child_OnDataPortalInvoke и OnDeserialized. Первые два метода вызываются серверной частью портала данных до вызова методов DataPortal_XXX бизнес-объекта. Первый метод — в случае если бизнес-объект является корневым, второй — если дочерним. Третий метод вызывается после десериализации мобильного объекта на сервере или клиенте. В рамках шаблона Repository его переопределять необязательно (зависимости используются только на сервере), но необходимо для общего случая внедрения зависимостей в бизнес-объекты CSLA.
Таким образом, мы можем написать метод Inject, который будет вызываться во всех трех методах и внедрять зависимости в созданный CSLA бизнес-объект. Исходя из всего вышесказанного напишем новый стереотип InjectableBusinessBase, который послужит заменой для стандартного стереотипа BusinessBase:
//InjectableBusinessBase.cs
[Serializable]
public abstract class InjectableBusinessBase : BusinessBase where T : BusinessBase {
protected override void DataPortal_OnDataPortalInvoke( DataPortalEventArgs e ) {
Inject( );
base.DataPortal_OnDataPortalInvoke( e );
}
protected override void Child_OnDataPortalInvoke( DataPortalEventArgs e ) {
Inject( );
base.Child_OnDataPortalInvoke( e );
}
protected override void OnDeserialized( System.Runtime.Serialization.StreamingContext context ) {
Inject( );
base.OnDeserialized( context );
}
private void Inject( ) {
// Здесь должен быть код для разрешения зависимостей данного экземпляра.
}
}
Заметим, что для каждого стереотипа бизнес-объектов CSLA должен быть создан новый стереотип с переопределенными якорями. Код новых стереотипов будет аналогичен коду выше. Теперь классы бизнес-уровня с зависимостями должны наследовать новым стереотипам:
[Serializable]
public partial class Person : InjectableBusinessBase {
//…
}
[Serializable]
public partial class Orders : InjectableBusinessListBase {
//…
}
[Serializable]
public partial class Address : InjectableBusinessBase {
//…
}
Для реализации метода Inject добавим следующий фасадный класс DI-контейнера (используется Ninject):
//Container.cs
public static class Container {
private static readonly object SyncRoot = new object( );
private static volatile IKernel _kernel; // в качестве DI-контейнера используется Ninject
public static IKernel Kernel {
get {
if ( _kernel == null ) {
lock ( SyncRoot ) {
if ( _kernel == null ) {
ConfigureKernel( );
}
}
}
return _kernel;
}
}
//Метод внедрения зависимостей в уже созданный объект.
public static void InjectInto( object target ) {
Kernel.Inject( target );
}
private static void ConfigureKernel( ) {
// конфигурация контейнера
}
public static void InjectKernel( IKernel kernel ) {
lock ( SyncRoot ) {
_kernel = kernel;
}
}
}
Как сконфигурировать непосредственно сам DI-контейнер нам пока неважно, а важен лишь метод InjectInto. Теперь можно вернуться к методу Inject () стереотипа InjectableBusinessBase:
private void Inject( ) {
Container.InjectInto( this );
}
Наконец, добавим свойства IPersonRepository и IContext в серверную часть класса Person и перепишем методы DataPortal_XYZ следующим образом:
//Person.Server.cs
public partial class Person {
public static readonly PropertyInfo LastChangedProperty =
RegisterProperty( c => c.LastChanged );
public object LastChanged {
get { return ReadProperty( LastChangedProperty ); }
private set { LoadProperty( LastChangedProperty, value ); }
}
[NonSerialized] [NotUndoable]
private IPersonRepository _personRepository;
[Inject]
[EditorBrowsable( EditorBrowsableState.Never )]
private IPersonRepository PersonRepository {
get { return _personRepository; }
set { _personRepository = value; }
}
[NonSerialized][NotUndoable]
private IContext _context;
[Inject]
[EditorBrowsable(EditorBrowsableState.Never)]
private IContext Context {
get { return _context; }
set { _context = value; }
}
protected override void DataPortal_Create( ) {
BusinessRules.CheckRules( );
}
private void DataPortal_Fetch( SingleCriteria idCriteria ) {
var personData = PersonRepository.FindPerson( idCriteria.Value );
if ( personData != null ) {
CopyValuesFrom( personData );
LoadProperty( OrdersProperty, Orders.GetOrders( personData ) );
LoadProperty( AddressProperty, Address.GetAddress( personData ) );
}
}
private void CopyValuesFrom( PersonData personData ) {
using ( BypassPropertyChecks ) {
DataMapper.Map( personData, this );
}
}
protected override void DataPortal_Insert( ) {
using ( var transaction = Context.BeginTransaction( ) ) {
try {
var personData = GetPersonData( );
int newId;
object lastChanged;
PersonRepository.AddPerson( personData, out newId, out lastChanged );
Id = newId;
LastChanged = lastChanged;
FieldManager.UpdateChildren( personData);
transaction.Commit( );
}
catch {
transaction.Rollback( );
throw;
}
}
}
protected override void DataPortal_Update( ) {
using ( var transaction = Context.BeginTransaction( ) ) {
try {
var personData = GetPersonData( );
object lastChanged;
PersonRepository.EditPerson( personData, out lastChanged );
LastChanged = lastChanged;
FieldManager.UpdateChildren( personData );
transaction.Commit( );
}
catch {
transaction.Rollback( );
throw;
}
}
}
private PersonData GetPersonData( ) {
// Обратите внимание, что поскольку в нашем случае имена свойств
//бизнес-класса Person и DTO PersonData совпадают, то можно воспользоваться
//классом CSLA DataMapper при работе с DTO, что делает код еще компактнее.
var personData = new PersonData( );
DataMapper.Map( this, personData, OrdersProperty.Name, AddressProperty.Name );
return personData;
}
private void DataPortal_Delete( SingleCriteria idCriteria ) {
PersonRepository.RemovePerson( idCriteria.Value );
}
protected override void DataPortal_DeleteSelf( ) {
PersonRepository.RemovePerson( Id );
}
}
Код дочерних классов:
//Orders.Server.cs
public partial class Orders {
[NonSerialized]
[NotUndoable]
private IOrderRepository _orderRepository;
[Inject]
[EditorBrowsable( EditorBrowsableState.Never )]
protected IOrderRepository OrderRepository {
get { return _orderRepository; }
set { _orderRepository = value; }
}
internal static Address GetAddress( Person person ) {
return DataPortal.FetchChild( person );
}
protected void Child_Fetch( PersonData person) {
var data = OrderRepository.FindOrders( person.Id );
RaiseListChangedEvents = false;
AddRange( data.Select( Order.GetOrder ) );
RaiseListChangedEvents = true;
}
protected void Child_Update( PersonData person ) {
base.Child_Update( person, OrderRepository );
}
}
//Order.Server.cs
public partial class Order {
internal static Order GetOrder( OrderData orderData ) {
return DataPortal.FetchChild( orderData );
}
protected void Child_Fetch( OrderData orderData ) {
using ( BypassPropertyChecks ) {
DataMapper.Map( orderData, this );
}
}
protected void Child_Insert( PersonData person, IOrderRepository orderRepository ) {
var data = GetOrderData( );
Id = orderRepository.AddOrder( person.Id, data );
}
protected void Child_Update( PersonData person, IOrderRepository orderRepository ) {
var data = GetOrderData( );
orderRepository.EditOrder( person.Id, data );
}
protected void Child_DeleteSelf( PersonData person, IOrderRepository orderRepository ) {
orderRepository.RemoveOrder( person.Id, Id );
}
private OrderData GetOrderData( ) {
var orderData = new OrderData( );
DataMapper.Map( this, orderData );
return orderData;
}
}
//Address.Server.cs
public partial class Address {
[NonSerialized, NotUndoable]
private IAddressRepository _addressRepository;
[Inject]
[EditorBrowsable( EditorBrowsableState.Never )]
protected IAddressRepository AddressRepository {
get { return _addressRepository; }
set { _addressRepository = value; }
}
internal static Address GetAddress( PersonData person ) {
return DataPortal.FetchChild( person );
}
protected void Child_Fetch( PersonData personData ) {
using ( BypassPropertyChecks ) {
var addressData = AddressRepository.FindAddress( personData.Id );
DataMapper.Map( addressData, this );
}
}
protected void Child_Insert( PersonData person ) {
var data = GetAddressData( );
Id = AddressRepository.AddAddress( person.Id, data );
}
protected void Child_Update( PersonData person ) {
var data = GetAddressData( );
AddressRepository.EditAddress( person.Id, data );
}
protected void Child_DeleteSelf( PersonData person ) {
AddressRepository.RemoveAddress( person.Id, Id );
}
private AddressData GetAddressData( ) {
var addressData = new AddressData( );
DataMapper.Map( this, addressData );
return addressData;
}
}
Специфичный код обращения к DAL исчез. Теперь перед обращением к методам DataPortal_XYZ серверный портал данных при помощи переопределенных якорей разрешит все зависимости класса Person, что позволит инкапсулировать весь код доступа к DAL в реализации репозиториев.
Идея этого способа взята из блога Johny Bekkum. Им создана библиотека CSLAContrib, которая содержит множество полезных дополнений к CSLA. В частности, в ней есть набор стереотипов CSLA, поддерживающих Property Setter Injection. Код этих стереотипов подобен коду, приведенному выше. В качестве DI-контейнера используется MEF (Managed Extensibility Framework), появившийся в .NET Framework 4.0.
Отметим, что всех сложностей можно избежать, просто использовав Container напрямую:
В данном случае класс Container используется как Service Locator, который часто определяют как антипаттерн. Однако данный способ тоже может быть полезен, особенно при сопровождении больших легаси проектов на CSLA.
CSLA via Repository Pattern
Рассмотрим подробнее реализацию шаблона Repository. Вынесем общий для всех будущих репозиториев код для работы с БД Oracle в базовый класс RepositoryBase:
В данном случае для обеспечения транзакций был использован класс CSLA TransactionManager, который позволяет использовать одно и то же соединение и ассоциированную с ним ADO .NET транзакцию во всем графе бизнес объекта при выполнении одной операции портала данных. Классы AddressRepository и OrderRepository аналогичны приведенному выше PersonRepository.
Диаграмма классов после всех изменений выглядит следующим образом:
Распределим бизнес-объекты, репозитории и контракты по разным проектам. Итоговая диаграмма пакетов выглядит так:
Наконец, добавим в CslaProject.DataAccess.OracleDb модуль Ninject для конфигурации DAL:
Вернемся к фасадному классу Container и для полноты примера приведем код конфигурации DAL в корневом проекте.
private static void ConfigureKernel( ) {
// InjectNonPublic = true, т.к. свойства закрыты
var kernel = new StandardKernel( new NinjectSettings {InjectNonPublic = true} );
// получение каталогов зависимостей.
var dependencyCatalogs = GetDependencyCatalogs( );
if ( dependencyCatalogs.Any( ) ) {
foreach ( var values in
dependencyCatalogs.Select( d => ConfigurationManager.AppSettings[ d ].Split( ';' ) ) ) {
var catalogPath = Path.Combine( AppDomain.CurrentDomain.BaseDirectory, values[ 0 ] );
IEnumerable depedencyLibNames;
if ( values.Count( ) > 1 ) {
var searchPattern = values[ 1 ];
depedencyLibNames = Directory.GetFiles( catalogPath, searchPattern );
}
else {
depedencyLibNames = Directory.GetFiles( catalogPath );
}
foreach ( var file in depedencyLibNames ) {
var dependency = Assembly.LoadFile( Path.Combine( catalogPath, file ) );
kernel.Load( dependency );
}
}
}
else {
//Если нет сконфигурированных зависимостей, загружаем все
//находящиеся в корневом каталоге сборки, название которых начинается с CslaProject
kernel.Load("CslaProject*.dll");
}
_kernel = kernel;
}
private static string[] GetDependencyCatalogs( ) {
return ConfigurationManager.AppSettings.AllKeys.Where(
p => p.StartsWith( "CslaProject.Depencies", true, CultureInfo.InvariantCulture ) ).ToArray( );
}
Читается App.Config примерно следующего вида:
Конфигурация зависимостей проекта задается в секции appSettings в опциях с ключом CslaProject.Dependencies. Значением опции является название каталога в корневом каталоге приложения, в котором расположены библиотеки с реализациями зависимостей.
Если у запускаемого проекта отсутствует App.Config с ключами CslaProject.Dependencies (например, если код бизнес-логики вызывается из проекта с юнит-тестами CslaProject.UnitTests), то подгружаются все сборки, название которых начинается с CslaProject. Так, если в проекте с юнит-тестами добавить модуль Ninject, который будет конфигурировать DAL тестовыми репозиториями, то в методах DataPortal_XYZ будут использоваться именно они.
Заключение
Рассмотренный способ отделения слоя доступа к данным от бизнес-классов CSLA вполне работоспособен. Однако есть и недостатки:
Все бизнес-классы должны наследовать новым стереотипам Injectables, что не всегда возможно.
Дополнительные накладные расходы. Метод внедрения зависимостей будет выполняться перед каждым вызовом методов DataPortal_XYZ и после десериализации на сервере или клиенте, что для бизнес-объекта с большим числом дочерних объектов может стать проблемой.
Увеличение сложности проекта.
Привязка к конкретному DI-контейнеру.
На этом, пожалуй, всё. Спасибо за внимание, и да пребудет с вами Сила.
Комментарии (2)
Bonart
1 ноября 2016 в 11:31
+2
↑
↓
И в чем же плюсы каркаса по сравнению, например, с Entity Framework + Autofac?
Масса шумового кода, два вида DTO, конструкторы без параметров, рефлексия на ровном месте, внедрения зависимости в свойства, помеченные атрибутами.
Выглядит как парад антипаттернов.
lair
1 ноября 2016 в 11:37
0
↑
↓
Эмм… репозиторий внутри доменной сущности? Репозиторий, который возвращает DTO? Это не репозиторий, это какой-то мутант, который им прикинулся.