Пример неправильного употребления Spring [закрывается]
Начиная с v5.2.0, Node.JS поставляется со встроенным тиковым процессором:
node --prof-process
См. Примечания к выпуску для получения дополнительной информации.
5 ответов
Из вашего описания (как говорили другие) невозможно судить, является ли полученный дизайн хорошим или плохим.
Конечная крайность IOC выглядит так: каждый полезный API завернутый в класс компонента. Параметры этого API предоставляются другими компонентами. Например, если приложению может потребоваться прочитать файл, у вас будет компонент (в псевдокоде):
public class ReadFile : IStreamFactory
{
IFilePath _path;
public ReadFile(IFilePath path)
{
_path = path;
}
// implementing IStreamFactory
Stream Get()
{
return new FileStream(_path.GetPathString());
}
}
Итак, теперь, чтобы сделать этот объект способным открывать поток в файле, вам нужно написать другой компонент, реализующий IFilePath. Вы могли бы написать несколько: компонент, который хранит постоянный путь к файлу (читается из конфигурации, конечно!), Компонент, который объединяет два пути к файлам, компонент, который берет обычный текст из другого компонента (реализует другой новый интерфейс, ITextSource?) И просто проверяет что это действительный путь.
Вы все равно поняли. Это почти как если бы вы выделяли каждую строчку обычного приложения и превращали эту строчку в отдельный компонент. Другой пример:
class IfThenElse : IAction
{
IBoolean _test;
IAction _ifTrue;
IAction _ifFalse;
// omitting obvious constructor
// implementing IAction
void Do()
{
if (_test.GetBool())
_ifTrue.Do();
else
_ifFalse.Do();
}
}
Вам понадобятся другие компоненты, представляющие «область действия, в которой могут быть объявлены переменные», а также «объявление именованной переменной» и «ссылку на переменную», которые должны каким-то образом работать с любым типом. компонента.
Итак, теперь вам нужно связать все эти крошечные фрагменты вместе в гигантский файл конфигурации XML, чтобы собрать их все вместе в приложение.
Если вы действительно сделали это на минимально возможном уровне, это будет довольно абсурдно, потому что задача написания XML-файла будет сравнима с написанием приложения обычным способом. За исключением того, что синтаксис будет основан на XML, имена всех функций будут совершенно нестандартными, и поддержка отладки будет отстойной.
Если вы можете найти "золотую середину" где-то выше этого, то ваш формат XML может быть тем, что пользователи предпочтут и найдут легче выучить, чем "сырое" программирование на основном языке.
Когда вы говорите «все одноэлементно», вы имеете в виду, что именно так это происходит в Spring? Я бы не ожидал, что сами типы (в коде) будут синглтонами - действительно, часть возможности конфигурировать вещи с помощью IoC состоит в том, чтобы избегать настоящих синглтонов (которые, например, усложняют тестирование).
Я могу На самом деле я не представляю, как лучше всего реализовать «поддержку нескольких файлов», о которой идет речь в вашем вопросе, не видя кода - но это, конечно, не должно быть слишком сложно. Есть разные способы подойти к этому: либо внедрить фабрику для соответствующего компонента, либо позволить вашему приложению попросить Spring создать компоненты, когда это необходимо. (Последний вариант более агрессивен с точки зрения зависимостей от Spring, но может означать менее шаблонный код.)
Это '
Динамическая конфигурация (например, изменение драйвера базы данных или замена слоя на фиктивный для тестирования) - лишь одно из многих преимуществ Spring и IoC в целом. Пожалуй, главное преимущество - полное разделение проблем. Все объекты становятся независимыми друг от друга, выполняют определенную задачу, и ответственность за их объединение лежит на контейнере.
Также в Spring концепция синглтона как-то отличается от синглтона шаблонов проектирования. Я бы сказал, что использование IoC подходит для любого приложения среднего или большого размера. Возможно, разработчики не имели большого опыта работы со Spring и не использовали некоторые из более сложных методов, которые действительно уменьшают размер кода и дают более элегантный результат.
Spring существует для того, чтобы не мешать и не ограничивать вас, но очищать весь код, который никто не хочет видеть или писать, а также поддержку тестирования / базы данных и т. Д.
Это правда, что технически возможно, например, заменить реализацию персистентности, но на самом деле это случается редко, и это повлияет на ваши интерфейсы, независимо от того, насколько они агностичны.
Лучшая причина для использования Весна, как я уже упоминал; тестирование ...
Я не слежу за вашим комментарием о том, что все является синглтоном, если это определенно решение, принятое вашим архитектором, потому что у вас может быть не-синглтон или прототипы в Spring, и вам рекомендуется это сделать где это необходимо, чтобы избежать анемичных моделей предметной области и классов, которые выглядят процедурными или написанными сценариями.
По опыту, который у меня был весной, я бы предпочел архитектуру, которая только бобов, которые, как вы знаете, являются одиночными, должны управляться пружиной. Другими bean-компонентами лучше управлять с помощью кода этих Spring-компонентов. iow, вручную.
Таким образом, существует сильное разделение между тем, что делает Spring, и тем, что делает приложение. Становится сложно использовать spring, и это дает преимущества, если вы используете его для объектов, отличных от singleton в вашем контексте, как вы сейчас испытываете.
Я признаю, что это не будет выполняться для каждой ситуации, но похоже, что это могло бы применяться в вашем.