Некоторые вопросы, связанные с каркасной зависимостью

Question

У меня есть несколько вопросов, связанных с каркасной зависимостью.Как правило, лучшая практика написания кода гласит, что не загромождайте свое пространство имен специфичным для фреймворка кодом.Например, в случае Spring вся зависимость должна быть сохранена в файле конфигурации, и в коде вашего приложения нет кода, специфичного для пружины (и это одна из причин, по которой предпочтение Spring xml-файла конфигурации стоит над аннотацией Spring).Точно так же в случае puremvc всегда предпочтительнее не смешивать код puremvc в mxml, чтобы ваше представление могло работать с любой средой.Но мой вопрос:

1. Если мы удалим spring или puremvc из вашего кода без замены какой-либо другой инфраструктуры, то вы окажетесь в нескольких bean-компонентах (в случае spring) или в действительно многократно используемых представлениях (в случае puremvc).Но склеивание bean-компонентов или представлений требует больших усилий по написанию кода, по моему мнению, это косвенная зависимость фреймворка без использования API, специфичного для фреймворка.

2. Если мы заменим пружину на другой DI-каркас, такой как пико-контейнер, то это также потребует значительного количества или переделки.Что снова приводит к косвенной зависимости от фреймворка.

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

По моему мнению, просто не смешивая пространство имен приложения с API, специфичным для фреймворка, не делает ваше приложение переносимым для других фреймворков.Подумайте, хотите ли вы перенести существующее хорошо спроектированное приложение для Struts с помощью Spring mvc и сколько усилий ему потребуется для этого.

Ожидайте представления от других читателей.

Answer 1

Я думаю, что это основной принцип разработки программного обеспечения, чтобы разделить ваши проблемы.Точно так же, как вы не хотите просматривать код на уровне модели в MVC, вам не нужен код, специфичный для контейнера, в коде приложения.

Вы правы, что во многих ситуациях нужно писать код для их инструментов,Например, вы можете написать некоторый код, специфичный для спящего режима, если вам нужен пользовательский тип, или некоторый код, специфичный для пружины, если вам нужен собственный контекст приложения.Там нет ничего плохого.Ключ должен держать это отдельно от других функциональных частей вашего приложения.

Это не гарантирует «мгновенную» переносимость.Что он продвигает, так это возможность «легко» перенести код в другое место.«Легко» в этом контексте не означает никакой работы.Скорее это означает, что вам не придется начинать вырывать специфические для Spring вещи, потому что вы решили перейти на Pico.Другими словами, ваша основная бизнес-функция остается неизменной, и все, что вам нужно сделать, это перенести конфигурацию или конкретные зависимости контейнера, когда вы решите переместиться.

Answer 2

Как и во всех абстракциях в разработке программного обеспечения, вы просто перемещаете «проблему», когда используете фреймворк. Фреймворк заботится об определенных вещах, поэтому другим частям вашего приложения не нужно знать, как это сделать. Например. если вы используете внедрение зависимостей, классы, которые вводятся, не должны знать, как создавать свои зависимости, это обрабатывается структурой внедрения зависимостей.

Но это только означает, что знание / ответственность перемещены. Никогда, никогда, 1003 * не перемещается. Так что да, конечно, ваш код неявно зависит от этой структуры. Но если вы перемещаете связанный с фреймворком код в одно место, возможно даже вводите некоторые интерфейсы для его переноса, вы можете иногда сделать так, чтобы остальная часть вашего кода зависела от интерфейса, класса или фреймворка, вместо конкретных рамок.

например. Я ввел в свой код интерфейс IIocContainer , используя только методы Resolve . Объект, реализующий этот интерфейс, обладает знанием , как вызывать конкретную платформу Ioc / DI. Но это знание только в этом одном объекте. Остальная часть моего приложения (где это необходимо) знает только об интерфейсе IIocContainer и поэтому не зависит от конкретной среды. Если я изменяю платформу, мне нужно только изменить ссылки и конфигурацию (которая может быть в XML и вообще не влиять на код) и использовать другой объект, который реализует IIocContainer для этого контейнера.

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

Я думаю, что вы можете сказать это просто так: если вы используете каркас, чтобы перенести проблему «много структурного сантехнического процесса» в эту каркас (пусть каркас обрабатывает сантехнику для вас), и вы переключаете каркас Вы сразу же получите проблему «много структурных сантехнических работ». : -)