Пружина-это структура с открытым исходным кодом, которая в основном реализует две вещи: МОК (управляющая инверсия) и AOP (программирование, ориентированное на раздел).
МОК
Контрольная инверсия, также известная как инверсия зависимости.
Так называемая зависимость, с точки зрения программы, означает, что, например, если A хочет вызвать метод B, то A зависит от B. В любом случае, если A хочет использовать B, A зависит от B. Так называемая инверсия, вы должны понимать, что произойдет, если он не будет перевернут, потому что A должен иметь B до того, как она может называть B. Если это не перевернуто, это означает, что это означает, что это означает, что это означает, что это означает, что это означает, что это означает. Чтобы получить экземпляры B (конечно, существуют различные шаблоны проектирования, которые могут помочь вам получить экземпляры B, такие как фабрики, локатор и т. Д.), И затем вы можете вызвать объект B. Следовательно, не перевернуто означает, что необходимо активно получать B перед использованием B; На этом этапе вы должны понимать значение перевернутого. Инвертирование означает, что если A хочет позвонить B, A не нужно активно получать B, но другие автоматически доставляют B к двери.
Так называемым изменением управления является передача мощности управления. Чтобы привести пример: если человек хочет водить, при нормальных обстоятельствах человек должен искать машину самостоятельно. После того, как изменение управления достигнуто, человеку не нужно рассматривать, откуда поступает автомобиль, просто ездит напрямую, и человек передает управление автомобилем на другие объекты. Испытать следующий код
Определите интерфейсную машину
открытый интерфейс CAR {void Go ();}Определите два типа автомобилей
открытый класс Benz реализует Car {public void go () {System.out.println ("Benz Go ..."); }} открытый класс BMW реализует car {public void go () {System.out.println ("bmw go ..."); }}Ниже приведено вождение
Public Class Person {Car Car = new Benz (); void rivecar () {System.out.println ("Begin Drive"); car.go (); }}Это нормальный процесс управления кодом. Если вы хотите ездить, вы должны создать экземпляр машины самостоятельно. Однако в этом случае этот человек может водить только одну машину. Как этот человек может управлять различными автомобилями? Это для достижения изменения контроля. Другими словами, если человек больше не создает самого машины, как человек может получить объект машины? Мы можем использовать инъекцию зависимостей (DI для краткости), чтобы получить объект автомобиля, тем самым достигнув контрольной инверсии. Итак, нам нужно изменить класс человека
открытый класс человек {Car Car = null; Public Person (Car Car) {this.car = car; } void rivecar () {System.out.println ("Begin Drive"); car.go (); }}Нынешний класс человека больше не создает самого объекта автомобиля, но использует конструктор для получения объекта автомобиля. Следовательно, этот класс может управлять различными автомобилями, если автомобиль реализует интерфейс автомобиля. Посмотрите, как пользоваться классом человека
public static void main (string [] args) {person p = new Person (new Benz ()); p.drivecar ();}Класс Человека может управлять более чем одним типом автомобиля, если вы передаете его через конструктор. В этом примере автомобильный объект является зависимостью класса человека. Когда мы создаем экземпляр класса человека, передача экземпляра автомобиля в класс человека - это инъекция зависимости. Таким образом, наш личный класс реализует инверсию контроля.
Что именно обратное изменение управления? Существует поговорка: так называемая управляющая инверсия-это процесс получения зависимостей объектов. После того, как контрольные права будут изменены, процесс получения зависимых объектов изменяется от собственного управления до инъекции контейнером МОК.
Весной реализует инъекцию зависимости
В вышеупомянутой строке кода человек p = новый человек (новый бенц ());, мы вручную новую объект бенза () и вводим его в класс человека. Spring не делает этого, потому что Spring чувствует, что ваша линия кода создает конкретный класс Benz. Если вы хотите создать создание класса BMW в будущем, не нужно ли вам изменить код? Тогда я просто напишу его в файле конфигурации. Даже если вам нужно обратить внимание в будущем, по крайней мере, вам не нужно изменять код, поэтому доступна следующая конфигурация.
<Beans> <bean id = "car" /> <bean id = "person"> <name = "car" ref = "car" /> <bean /> < /beans>
Затем пружина обеспечивает некоторые механизмы. При получении объекта класса человека из файла конфигурации, объект CAR, который он поступает, будет собираться, и объект Person не должен беспокоиться о том, в каком конкретном классе передается. Следовательно, пружина, как структура IOC, в основном предпринимает два шага: создание объекта и сборка отношений между объектами.
Аоп
AOP (ориентированное на аспект программирование) является ориентированным на аспект программирования. Позвольте мне привести вам пример того, что такое аспект. В полном проекте веб -сайта необходимо регистрировать многие модули, необходимо войти в систему множество мест, и многие места должны быть обработкой исключений. Регистрация, ведение журнала, обработка исключений и другая логика являются так называемыми разделами. Предполагая, что я пишу логику этих разделов повсюду, можно представить, что поддержание кода можно представить. AOP - это достижение разделения проблем, извлечение логики этих разделов и записать их в отдельные классы, а затем найти способ собрать их с общими модулями для выполнения. Обычные модули даже не знают, что они собрали их с разделами и разделами.
Цель программирования, ориентированного на аспект, состоит в том, чтобы разделить фокус. Что фокус? Это то, что вы должны сделать, это фокус. Если вы молодой человек и у вас нет жизненных целей, вам просто нужно носить одежду и есть, и вы знаете только одну вещь, чтобы играть весь день! Итак, каждый день, когда вы открываете глаза, вы просто хотите играть после обеда (вещи, которые вы должны делать), но перед игрой вам также нужно носить одежду, носить обувь, сложить стеганые одеяла, готовить и т. Д. Все эти вещи остаются для других. Прежде чем идти к обеденному столу, есть специальный слуга, чтобы помочь вам одеться, слуга B, который поможет вам надеть обувь, слуга C, чтобы помочь вам сложить одеяло, слуга C, чтобы помочь вам готовить, а затем вы начинаете есть и играть (это ваш день вашего дня). После того, как вы закончите свой день, вернитесь, и серия слуг начнет помогать вам сделать это и это, а затем день закончился!
Преимущество AOP заключается в том, что вам нужно только делать свой важный бизнес, а другие помогут вам с другими вещами. Может быть, однажды, если вы хотите бежать голым и не хотите носить одежду, то вы просто уволите слугу! Может быть, однажды вы хотите принести немного денег перед выходом на улицу, чтобы вы могли нанять другого слуги D, чтобы помочь вам получить деньги! Это AOP. Каждый выполняет свои собственные обязанности и гибко объединяется для достижения настраиваемой, подключаемой структуры программы.
С точки зрения весны, самой большой целью AOP является предоставление возможностей управления транзакциями. Управление транзакциями - это внимание. Ваш бизнес должен получить доступ к базе данных, и вы не хотите управлять транзакциями (слишком раздражающими). Следовательно, Spring автоматически запустит транзакцию перед тем, как вы получите доступ к базе данных, и автоматически совершат/отменит транзакции для вас после доступа к базе данных!
Посмотрите на следующий код, не имеет значения, если вы этого не понимаете
<Bean id = "Audiure" /> <AOP: config> <aop: Aspose ref = "Аудитория"> <aop: pointcut id = "expression =" expression = "exepress =" exepress (* com.springinaction.springidol.performer.perform (..)) " /> <aop: до portcut-ref =" method = " /> <! <aop: перед pointcut-ref = "performance" method = "surfcelphones" /> <!-<co id = "co_refpointcut" />-> <aop: после возврата pointcut-ref = "method =" Applead " /> <!-<co Id =" co_refpointcut " />> <aproad" /> <! method = "DemandRefund"/> <!-<co id = "co_refpointcut"/>-> </aop: аспект> </aop: config>
Примерно смысл приведенной выше конфигурации заключается в том, что когда будет происходить метод исполнителя. Перед выполнением целевого метода сначала выполните методы Audience.takeseats () и Audienceturn.offcellphones (), а затем запустите целевой метод. Когда целевой метод выполняется и возвращается, запустите метод audienceturn.applaud (). Если целевой метод, к сожалению, бросает исключение, агент запустит метод audienceturn.demandrefund (). Короче говоря, класс прокси -сервера Spring контролирует выполнение целевого метода во всех аспектах, в то время как целевой метод фокусируется только на своих собственных делах и даже не знает существования класса прокси.
Суммировать
Выше приведено все о простом понимании примеров IOC, AOP и кода Spring. Я надеюсь, что это будет полезно для всех. Заинтересованные друзья могут продолжать ссылаться на этот сайт:
Подробное введение в реализацию симуляции IOC весны
Весенний AOP перехват-три способа реализации автоматического прокси-объяснения
Если есть какие -либо недостатки, пожалуйста, оставьте сообщение, чтобы указать это. Спасибо, друзья, за вашу поддержку на этом сайте!