Фаулер М. Архитектура корпоративных программных приложений
Подождите немного. Документ загружается.
224 Часть II. Типовые решения
дополнительных данных необходимо отдельное обращение к базе данных и когда извле-
каемые данные не используются вместе с основным объектом.
Применение загрузки по требованию существенно усложняет приложение, поэтому
я стараюсь прибегать к ней только тогда, когда без нее действительно не обойтись.
Пример: инициализация по требованию (Java)
Суть инициализации по требованию описывается примерно следующим образом:
class Supplier...
public List getProducts() {
if (products == null) products =
Product.findForSupplier(getID() ) ;
return products; }
В этом примере первая попытка доступа к полю products приводит к загрузке его
значения из базы данных.
Пример: виртуальный прокси-объект (Java)
Для обеспечения работы виртуального прокси-объекта необходимо создать класс,
сходный с используемым реальным классом, однако представляющий собой всего лишь
простую оболочку последнего. В нашем примере список товаров, заказанных у постав-
щика, будет храниться в обычном поле типа List.
class SupplierVL...
private List products;
Самое сложное в создании прокси-объекта для списка — настроить его так, чтобы ре-
альный список создавался только тогда, когда он будет затребован. Для этого создавае-
мому экземпляру виртуального списка необходимо передать код, применяемый для соз-
дания реального списка. В Java это лучше осуществить путем определения интерфейса
загрузчика.
public interface VirtualListLoader {
List load(); }
Теперь можно создать экземпляр виртуального списка с помощью загрузчика, кото-
рый будет вызывать соответствующий метод отображения.
class SupplierMapper...
public static class ProductLoader implements
VirtualListLoader { private Long id; public
ProductLoader(Long id) { this.id = id;
Глава 11. Объектно-реляционные типовые решения... 225
}
public List load(){
return ProductMapper.create().findForSupplier(id) ;
Во время выполнения загрузки экземпляр загрузчика товаров передается создаваемо-
му экземпляру виртуального списка, который затем присваивается полю products.
class SupplierMapper...
protected DomainObject doLoad(Long
id, ResultSet rs)
throws SQLException {
String nameArg = rs.getString(2); SupplierVL result =
new SupplierVL(id, nameArg); result.setProducts(new
VirtualList
(new
ProductLoader (id)));
return result;
)
Поле source класса VirtualList является самоинкапсулированным. При первом
обращении к реальному списку оно вызывает метод загрузки для извлечения списка за-
казанных товаров из базы данных.
class VirtualList...
private List source;
private VirtualListLoader loader;
public VirtualList(VirtualListLoader loader) {
this.loader = loader; }
private List getSourceO {
if (source == null) source - loader.load();
return source; }
Все методы работы с обычным списком реализуются в классе virtualList для спи-
ска source.
class VirtualList...
public int sized {
return getSource().size();
} public boolean isEmptyO {
return getSource().isEmpty();
)
//...и т .п . для всех остальных методов списка
Теперь класс домена ничего не будет "знать" о том, как класс преобразователя выполняет
загрузку по требованию. Более того, класс домена вообще не узнает о том, что она есть.
226 Часть II. Типовые решения
Пример: использование диспетчера значения (Java)
Диспетчер значения может быть использован в качестве универсальной загрузки по
требованию. В этом случае классу домена известно об использовании загрузки по требова-
нию, поскольку поле products имеет тип ValueHolder. Данный факт может быть скрыт
от клиентов поставщика посредством get-метода.
class SupplierVH...
private ValueHolder products;
public List getProducts () {
return (List)products.getValue();
}
Объект ValueHolder сам выполняет функции, возложенные на загрузку по требова-
нию. Чтобы держатель значения смог загрузить требующиеся данные, ему необходимо
передать соответствующий код. Это можно сделать путем определения интерфейса за-
грузчика.
class ValueHolder...
private Object value;
private ValueLoader loader;
public ValueHolder(ValueLoader loader) {
this.loader =loader; }
public Object getValue() {
if (value == null) value = loader.load();
return value;
} public interface
ValueLoader {
Object load();
}
Преобразователь может установить диспетчер значения, создав реализацию загрузчи-
ка и поместив ее в объект поставщика.
class SupplierMapper...
protected DomainObject doLoad(Long id, ResultSet rs)
4>throws SQLException {
String nameArg = rs.getString(2) ; SupplierVH result =
new SupplierVH(id, nameArg); result.setProducts(new
ValueHolder(new 4>ProductLoader(id)));
return result;
}
public static class ProductLoader implements ValueLoader {
private Long id; public ProductLoader(Long id) {
this.id = id; }
public Object load() {
Глава 11. Объектно-реляционные типовые решения... 227
return ProductMapper.
create().findForSupplier(id); } }
Пример: использование фиктивных объектов (С#)
Большая часть логики по превращению объектов в фиктивные может быть реализо-
вана в супертипах слоя (Layer Supertype, 491). Как следствие этого, если вы начнете при-
менять фиктивные объекты, они будут использоваться везде. Я начну изучение фиктив-
ных объектов с рассмотрения супертипа слоя объектов домена. Каждому объекту домена
известно, является он фиктивным или нет.
class DomainObject...
LoadStatus Status;
public DomainObject (long key) {
this.Key = key; }
public Boolean IsGhost {
get {return Status == LoadStatus.GHOST;}
} public Boolean IsLoaded {
get {return Status == LoadStatus.LOADED;}
} public void MarkLoading() {
Debug.Assert(IsGhost) ;
Status = LoadStatus.LOADING;
) public void MarkLoadedO {
Debug.Assert(Status == LoadStatus.LOADING);
Status =LoadStatus.LOADED;
} enum LoadStatus {GHOST, LOADING,
LOADED};
Объекты домена могут иметь три состояния: фиктивный (ghost), загружаемый
(loading) и загруженный (loaded). Я предпочитаю помещать информацию о состоянии в
поля, доступные только для чтения, и выполнять изменение их значений посредством
соответствующих явных методов.
Что самое утомительное при работе с фиктивными объектами, это необходимость из-
менить каждый метод доступа. Последний должен проверить, не является ли объект фик-
тивным, и, если это так, запустить метод загрузки его содержимого.
class Employee...
public String Name {
get {
Load();
return _name;
} set {
Load();
_name =value;
228 Часть II. Типовые решения
} }
String
_name;
class Domain Object...
protected void Load() {
if (IsGhost)
DataSource.Load(this) ;
}
Для любителей аспектно-ориентированного программирования подобная необходи-
мость изменения методов доступа — замечательный повод прибегнуть к последующей
обработке байт-кода.
Для выполнения загрузки содержимого объект домена должен вызвать нужный пре-
образователь. Между тем, согласно моим правилам "видимости", код объекта домена не
может "видеть" код преобразователя. Чтобы избежать подобной зависимости, необходи-
мо реализовать интересную комбинацию реестра (Registry, 495) и отделенного интерфейса
(Separated Interface, 492), как показано на рис. 11.4. В реестр домена будут помещены ме-
тоды для работы с источником данных.
class DataSource...
public static void Load (DomainObject obj) {
instance.Load(obj); }
Экземпляр источника данных определяется с помощью интерфейса.
class DataSource...
public interface IDataSource {
void Load (DomainObject obj ) ; }
Интерфейс источника данных реализуется в реестре преобразователей, определенном
в слое источника данных. В нашем примере преобразователи помещены в словарь, ин-
дексированный по типам домена. Метод загрузки находит нужный преобразователь и
указывает ему на необходимость загрузки соответствующего объекта домена.
class MapperRegistry : IDataSource...
public void Load (DomainObject obj) {
Mapper(obj.GetType()).Load (obj); } public
static Mapper Mapper(Type type) {
return (Mapper) instance.mappers[type]; )
IDictionary mappers = new Hashtable();
Рис. 11.5. Последовательность загрузки фиктивного объекта
230 Часть И. Типовые решения
В приведенном фрагменте кода показано, как объекты домена взаимодействуют с ис-
точником данных. Логика источника данных использует преобразователи данных (Data
Mapper, 187). Логика обновления, реализованная в преобразователях, точно такая же,
как и без использования фиктивных объектов. В данном случае гораздо больший интерес
представляют методы поиска и загрузки.
Конкретные классы преобразователей имеют собственные методы поиска, которые
вызывают абстрактный метод поиска и приводят полученное значение к типу своего
класса.
class EmployeeMapper...
public Employee Find (long key) {
return (Employee) AbstractFind(key); }
class Mapper...
public DomainObject AbstractFind (long key) {
DomainObject result;
result = (DomainObject) loadedMapfkey];
if (result == null) {
result = CreateGhost(key);
loadedMap.Add(key, result);
}
return result;
}
IDictionary loadedMap = new Hashtable(); public abstract
DomainObject CreateGhost(long key);
class EmployeeMapper...
public override DomainObject CreateGhost(long key) {
return new Employee(key);
}
Как видите, метод поиска возвращает фиктивный объект. Реальное содержимое объ-
екта не загружается из базы данных до тех пор, пока не будет осуществлена попытка дос-
тупа к одному из свойств объекта домена, в результате чего метод доступа запустит вы-
полнение загрузки.
class Mapper...
public void Load (DomainObject obj) {
if ( !obj.IsGhost) return;
IDbCommand comm = new OleDbCommand(findStatement(),
DB.connection) ;
comm.Parameters.Add(new OleDbParameter("key",
obj.Key));
IDataReader reader = comm.ExecuteReader();
reader.Read();
LoadLine (reader, obj);
reader.Close (); }
Глава 11. Объектно-реляционные типовые решения... 231
protected abstract String findStatement(); public
void LoadLine (IDataReader reader, ^DomainObject
obj) {
if (obj.IsGhost) {
obj.MarkLoading(); doLoadLine
(reader, obj); obj.MarkLoaded();
} }
protected abstract void doLoadLine (IDataReader reader,
^DomainObject obj);
Как и в предыдущих примерах, супертип слоя выполняет все действия, вынесенные в
абстрактный класс, после чего вызывает абстрактный метод для конкретного производ-
ного класса. В этом примере я воспользовался объектом DataReader — моделью поточ-
ного считывания данных с помощью курсора, которая сегодня применяется на различ-
ных платформах. При желании можете расширить данный пример на использование
объекта DataSet, более популярного в среде .NET.
В нашем примере у объекта Employee ("сотрудник") есть три типа свойств: поле Name
("имя"), имеющее простое значение типа string, поле Department ("отдел"), значение
которого является ссылкой на другой объект, и поле TimeRecords ("трудовой стаж"),
значением которого является коллекция. Загрузку всего этого содержимого выполняет
реализация метода doLoadLine () в производном классе (рис. 11.5).
class EmployeeMapper...
protected override void doLoadLine (IDataReader reader,
^DomainObject obj) {
Employee employee = (Employee) obj;
employee.Name = (String) reader["name"];
DepartmentMapper depMapper = ^(DepartmentMapper)
MapperRegistry.Mapper(typeof(Department));
employee.Department =
'bdepMapper.Find((int)reader["departmentID"] ) ;
loadTimeRecords(employee) ; }
Значение поля Name зафужается путем простого считывания значения соответствую-
щего столбца, на которое указывает курсор объекта DataReader. Значение поля De-
partment считывается с помощью метода поиска объекта DepartmentMapper. В резуль-
тате применения этого метода значением поля Department станет фиктивный объект;
настоящие данные об отделе будут считаны только тогда, когда кто-то попытается осу-
ществить доступ К самому объекту Department.
С коллекцией дело обстоит немного сложнее. Чтобы избежать волнообразной зафуз-
ки, все записи о стаже работы должны быть извлечены посредством одного запроса.
Для этого понадобится особая реализация списка, которая будет выступать в роли фик-
тивного списка. Последний является всего лишь оболочкой реального списка и передает
ему управление всеми действиями, затрагивающими содержимое списка. Единственное,
что делает фиктивный список, — это следит за тем, чтобы любая попытка доступа к спи-
ску приводила к выполнению зафузки.
Рис. 11.4. Классы, принимающие участие в загрузке фиктивного объекта
Глава 11. Объектно-реляционные типовые решения... 233
class DomainList...
IList data {
get {
Load(); return
_data; }
set {_data = value;}
}
IList _data = new ArrayList() ;
public int Count {
get {return data.Count;} }
Класс DomainList используется объектами домена и является частью слоя домена.
Методу, выполняющему загрузку, необходимо иметь доступ к SQL-командам, поэтому я
воспользовался делегатом для определения функции загрузки, которая может быть пре-
доставлена слоем отображения (рис. 11.6).
class DomainList...
public void Load () { if
(IsGhost) {
MarkLoading();
RunLoader(this);
MarkLoaded();
} }
public delegate void Loader(DomainList list);
public Loader RunLoader;
Для большей наглядности делегат можно представить себе в качестве особой разно-
видности отделенного интерфейса для одной функции. Действительно, вместо использо-
вания делегата можно было бы объявить интерфейс, содержащий единственную функцию.
У самого загрузчика ListLoader есть свойства, задающие SQL-выражение, парамет-
ры этого выражения и преобразователь, которые следует использовать для загрузки запи-
сей о трудовом стаже. Объект EmployeeMapper устанавливает значения полей объекта
ListLoader при зафузке объекта employee.
class EmployeeMapper...
void loadTimeRecords(Employee employee) { ListLoader loader
= new ListLoader(); loader.Sql =
TimeRecordMapper.FIND_FOR_EMPLOYEE_SQL;
loader.SqlParams.Add(employee.Key) ; loader.Mapper =
MapperRegistry.Mapper( typeof(TimeRecord));
loader.Attach ((DomainList) employee.TimeRecords); )
class ListLoader...