Как лучше всего хранить XML / CSV / другое представление объекта - PullRequest
3 голосов
/ 04 января 2009

Когда объект имеет различные форматы (XML, CSV), он может быть представлен там, где следует хранить знания об этих форматах.

Если объект знает о том, как он представлен в XML (то есть позволяет объекту преобразовывать себя через некоторый метод объекта, такой как GetXML()). Не слишком ли много знаний для объекта, и должно ли оно храниться извне в хранилище / сервисе / другом слое?

Если он хранится в репозитории, что происходит в случае использования, когда XML-представление объекта должно быть сохранено в базе данных вместе с другой информацией, например, :-

insert into order values(1, '2004', <order><amount>2</amount><price>19.99</price></order>);

... знание структуры XML объекта будет в репозитории XML, однако для репозитория SQL эти знания также потребуются, и это похоже на дублирование.

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

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

Ответы [ 2 ]

5 голосов
/ 04 января 2009

Вообще говоря, вы хотите, чтобы код форматирования XML (или другого ...) объекта был отдельным для самого объекта. Практическая причина этого заключается в желании иметь более одного представления XML (скажем, краткое и подробное представление). Если эти методы используют всю часть API объекта, вы начинаете иметь:

public String GetShortXml(){ ... }
public String GetFullXml(){ ... }
public String GetCsv(){ ... }
public String GetJson(){ ... }

Как часть API каждого бизнес-объекта, и это становится ужасно быстрым. Кроме того, это нарушает принцип единоличной ответственности , поскольку каждый класс отвечает за то, что делает id, и представляет себя как XML, JSON, CSV и т. Д.

Таким образом, часто лучше иметь класс, который знает, как форматировать интересующие вас бизнес-объекты, и иметь SummaryXmlFormatter, DetailXmlFormatter, CsvFormatter, JsonFormater и т. Д.

Вы можете сделать еще один шаг, и ваши объекты реализуют интерфейс IFormattable (ниже приведена адаптация шаблона для посетителей , который дает нам двойное качество отправки):

public interface IFormattable {
    public String Format(IFormatter formatter);
}

с реализациями вроде:

public String Format(IFormatter formatter){
    return formatter.FormatBusinessObjectOne(this);
}

с интерфейсом IFormatter, определенным таким образом:

public interface IFormatter{
    public String FormatBuisinessObjectOne(BusinessObjectOne boo);
    public String FormatBuisinessObjectTwo(BusinessObjectTwo bot);
    ...
}

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

Ваши вызовы для форматирования будут выглядеть следующим образом:

IFormatter formatter = new XmlFormatter();
BusinessObjectOne boo = new BusinessObjectOne(...);

// With visitor like double dispatch
String xml = boo.Format(formatter);

// Without 
String xml = formatter.FormatBusinessObjectOne(boo);

// With overloading
String xml = formatter.Format(boo);
0 голосов
/ 04 января 2009

Что вы хотите хранить в БД?

insert into order 
values(1, '2004', '<order><amount>2</amount><price>19.99</price></order>');

или

insert into order values(1, '2004', 2, 19.99); 

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...