Объект должен исписаться в файл, или другой должен возразить действию на нем для выполнения ввода-вывода?
Все, что «просто работает» с Spring Boot, на самом деле не более, чем какая-то конфигурация. В конце концов, это всего лишь приложение Spring. Поэтому я считаю, что вы, вероятно, можете настроить все вручную, что Boot делает для вас автоматически, но я не знаю никого, кто бы на самом деле пробовал этот конкретный угол. Создание контекста приложения начальной загрузки, безусловно, является предпочтительным подходом, но в зависимости от вашего варианта использования вы можете заставить его работать с одним контекстом, если убедитесь, что локаторы источника свойств выполняются достаточно рано.
Приложения, отличные от Spring (или не Spring Boot), могут получать доступ к обычному тексту или двоичным файлам на сервере конфигурации. Например. весной вы можете использовать @PropertySource с расположением ресурса, который был URL-адресом, например http://configserver/{app}/{profile}/{label}/application.properties или http://configserver/{app}-{profile}.properties. Все это описано в руководстве пользователя.
7 ответов
Правильный подход, в общем, - это ваш Случай 1. Он поддерживает единственную ответственность за класс (что бы он ни делал), не связывая его с конкретным механизмом сохранения (диском).
Вы рассматриваете конкретный случай более общей проблемы: сериализацию. Это хорошо и нормально, если у объекта есть средства, указывающие, как он должен быть сериализован - в конце концов, это единственный объект, который знает, что необходимо для его десериализации. Но если вы заставляете объект сохранять себя на диск, вы тесно связали этот объект с конкретной реализацией.
Вместо этого рассмотрите возможность создания интерфейса, который обобщенный «писатель» может использовать для «сериализации» объекта во все, что этот писатель сериализуется в. Таким образом, вы сможете сериализовать на диск, в сеть, в память, к тому, что вам действительно нужно сериализовать. :)
Это пример того, как можно использовать Шаблон разработки стратегии . Ваш объект myBob может иметь экземпляр класса, который его запишет. Вы можете захотеть, чтобы писатель реализовал интерфейс или был унаследован от абстрактного класса, чтобы можно было легко изменить процедуру сохранения.
Сегодня вы сохраняете в xml, но в конечном итоге вам может потребоваться сохранить объект и в базе данных. Этот шаблон позволит вам легко изменить процедуру сохранения. У вас даже будет возможность изменить способ сохранения во время выполнения.
Я бы сказал Бобу , что он знает, как сериализовать себя, поскольку у него есть личные данные. Другой объект (например, ваш Writer ) возьмет это и поместит на диск. Боб знает, как лучше всего обращаться со своими данными, но ему не нужно заботиться о том, как и где они хранятся. Ваш Writer лучше всех умеет сохранять данные, но ему не нужно заботиться о том, как эти данные создаются.
Раньше я предпочитал вариант 2; однако, поскольку я начал действительно пытаться понять и смоделировать области, над которыми я работаю, я предпочитаю вариант 1.
Представьте, что вы моделируете Транспортные средства. Почему автомобиль должен знать, как сохранять самообладание? Он может знать, как двигаться, как начинать и как останавливаться, но что такое «Сохранить» в контексте транспортного средства.
Сделайте следующее:
public interface Writable {
public void Save(Writer w);
}
public interface Writer {
public void WriteTag(String tag, String cdata);
}
public class Bob : Writable {
private String ssn = "123-23-1234";
public void Save(Writer w) {
w.WriteTag("ssn", ssn);
}
}
public class XmlWriter : Writer {
public XmlWriter(Sting filename) {...}
public void WriteTag(String tag, Sting cdata) {...}
}
Очевидно, что это не полное решение, но вы должны получить общая идея.
Еще один метод - использовать шаблон посетителя. Пусть ваш объект содержит метод Accept, который проходит через элементы, которые вы хотите обработать / сериализовать, и пусть посетитель будет вашим сериализатором. Всякий раз, когда вы обновляете или изменяете сериализацию (простой текст в xml на двоичный код для чего угодно), вам не нужно обновлять объект.
У нас был хороший опыт работы, когда мы поступали таким образом. Он довольно мощный.
Я думаю, что правильным подходом является случай 1, но ваш класс может быть определен таким образом, чтобы использовать преимущества обоих подходов:
class Bob {
IWriter _myWriter = null;
public Bob(){
// This instance could be injected or you may use a factory
// Note the initialization logic is here and not in Save method
_myWriter = new Writer("c://bob.xml")
}
//...
public void Save(){
_myWriter.Write(this);
}
// Or...
public void Save(string where){
_myWriter.Write(this, where);
}
//...
}
Это можно легко изменить, чтобы поместить логику записи и инициализацию в базовом классе, поэтому класс Боба еще чище и не зависит от постоянства.