Тази статия се нуждае от подобрение. Необходимо е: форматиране. Ако желаете да помогнете на Уикипедия, използвайте опцията редактиране в горното меню над статията, за да нанесете нужните корекции. |
ВНИМАНИЕ: Тази статия се нуждае от частичен или цялостен превод. Ако имате познания по използвания език, не се колебайте! Чуждият текст, който не е преведен до 2 седмици след поставянето на шаблона, ще бъде изтрит. Благодарим Ви, че помагате на Уикипедия! |
Spring Framework | |
Информация | |
---|---|
Разработчик | Pivotal Software |
Начална версия | 1 октомври 2002 г. |
Последна версия | 4.1.5[1] |
Програмен език | Java (programming language) |
Операционна система | Cross-platform |
Платформа | Java Virtual Machine |
Статус | Active |
Вид софтуер | Application framework |
Лиценз | Apache License 2.0 |
Уебсайт | spring.io |
Spring Framework в Общомедия |
Spring Framework е технологична рамка (framework) с отворен код (open source) за Java платформата. Spring framework предоставя много функции, които улесняват разработването на Java-базирани enterprise приложения.
Spring Framework включва различни модули, които предоставят широк набор от функционалности:
Основното ядро в Spring Framework е неговият IoC (Inversion of Control) контейнер, който осигурява логически средства за конфигуриране и управление на Java обекти с помощта на reflection. Контейнерът е отговорен за управлението на жизнения цикъл на специфични обекти: създаването на тези обекти, извикването на инициализиращите им методи и конфигурирането им свързвайки ги заедно. Обектите, създадени от контейнера се наричат още управлявани обекти или бийнове (beans). Контейнерът може да бъде конфигуриран чрез зареждане на XML файлове или засичането на специфични Java анотации от конфигуриращите класове.
Обектите могат да бъдат получени чрез dependency lookup или dependency injection. Dependency injection е софтуерен шаблон за дизайн, който опростява обектно ориентираното програмиране (ООП) чрез намаляване на зависимостите между отделните класове. Така при създаването на един проект, използвайки някой обектно ориентиран език се избягва зависимостта от конкретни имплементации, и се набляга повече на абстракции. Това се нарича още обръщане на контрола (inversion of control) – когато модулите от високо ниво не зависят от модули от по-ниско ниво.
При dependency injection обектите се проектират по начин, при който те получават инстанции на обекти от различен външен модул код, вместо да са конструирани вътре в него. Dependency injection включва най-общо три елемента:
Зависимият елемент определя на какъв софтуерен компонент зависи за да си свърши работата, а контейнерът решава какви конкретни класове отговарят на изискванията на зависимия обект, и ги предоставя като зависимости. По този начин контейнерът по свой избор, може да променя конкретните имплементации, които се използват по време на изпълнение на програмата (run-time), а не по време на компилация (compile-time). По време на изпълнение (run-time) могат да бъдат създадени множество различни инстанции на даден софтуерен компонент, без значение, каква конкретна е била инжектирана.
Това позволява кодът, който пишем да е много по модуларен и разкачен, което го прави в същото време и много по-тестваем.
Аспектно-ориентираното програмиране (АОП) е относително нова парадигма в програмирането която цели да се увеличи модулността на софтуера и включва методи и инструменти които помагат за това.
Почти всички програмни парадигми поддържат някакво ниво на групиране и капсулиране на проблеми в отделни, независими части чрез представянето им чрез абстракции (например, функции, процедури, модули, класове, методи), които могат да бъдат използвани за изпълнение, абстрахиране и композиране на отношения. Някои отношения „пресичат“ множество абстракции в програмния код, и се наричат междусекторни отношения.
Като пример, може да се посочи „логването“ в дадена система, тъй като в зависимост от избрания вход в системата, поведението на всички методи и класове може да е различно.
Аспект наричаме единица, която капсулира дадено отношение, което пресича системните елементи в множество точки. Техниката на програмиране, която се занимава с тези дизайн проблеми се нарича Аспектно-ориентирано програмиране (АОП). Аспектно-ориентираното разработване на софтуер (АОРС) е нова технология, която се опитва да наложи АОП в масовото производство на софтуер с цел по-добро разграничение и моделиране на отношенията. Аспектите се ползват във всяка една стъпка от цикъла на производствения процес. Типични примери за аспекти са: сигурност, качество на услугата (QoS), поддръжка на трансакции, синхронизация, трасиране и т.н.
Така наречените Spring frameworks за достъп на данни се отнасят за често срещани проблеми при работа с база данни, които разработчиците срещат. Както следват всички най-известни frameworks за достъп на данни в Java се поддържат: JDBC, iBatis/MyBatis, Hibernate, JDO, JPA, Oracle TopLink, Apache OJB, и Apache Cayenne и други.
За всички изброени дотук frameworks, Spring поддържа следните характеристики:
Всички тези възможности са достъпни когато се използват шаблонни класове (template classes) предоставени за всеки framework който Spring поддържа. Критиците казват, че тези шаблонни класове са натрапчиви и не предлагат предимства пред използването примерно на Hibernate API directly. В отговор на това, разработчиците на Spring направиха възможно използването на Hibernate и JPA APIs directly. Това от своя стана изисква използването на управление на прозрачни трансакции, тъй като кода на приложението вече не поддържа свойството за получаване и затваряне на ресурси от базата данни, и не поддържа уникални трансакции.
Заедно с управлението на Spring's трансакции, този framework предлага гъвкава абстракция за работа с frameworks за достъп на данни. Spring Framework не предлага стандартен API достъп на данни; вместо това цялата мощ на поддържащото API е оставена непокътната. Spring Framework е единствения framework достъпен за Java, който предлага управление на достъпа до данните извън сървъра или контейнера на приложението.
При използването на Spring за управление на трансакциите с Hibernate, най-вероятно следните продукти ще трябва да се конфигурират:
Други стъпки от конфигурирането включват както следва:
Управление на трансакциите видове:
Глобалната поддръжка на операциите/трансакциите е една от многото причини да се използва Spring Transaction management framework. The Spring Framework предоставя последователна абстракция за управление на операциите/трансакциите, която осигурява следните предимства:
Конфигурации на управлението на трансакциите:
<bean id = “transactionManager” class = “org.springframework.jdbc.datasource.DateSourceTransactionManager”> <propertyname = “dateSource” ref = “dataSource”/> </bean>
<bean id = “transactionManager” class = “org.springframework.orm.hibernate3.HibernateTransactionManager”> <propertyname = “sessionFactory ref = “sessionFactory”/> </bean>
Platform Transaction Manager мениджъра на трансакциите включва:
Мениджъра на трансакциите е част от приложение, което отговаря за координирането на операциите/трансакциите през един или повече ресурси. В Spring framework мениджърът на трансакциите е ефективно в основата на системата на операциите.
Отговорностите на мениджъра на трансакции са следните:
Разграничаване – започващи и завършващи операции, използвайки begin, commit, and rollback методи.
Управление на контекста на трансакцията – контекст на трансакцията съдържа информацията, от която мениджър на трансакциите се нуждае, за да продължи следенето на трансакцията/операцията. Мениджъра на трансакциите е отговорен за създаването на контекст операцията и закрепването му към текущата нишка.
Координиране на трансакциите през множество ресурси – трансакциите от корпоративно ниво обикновено имат способността да координират операции от множество ресурси. Тази функция изисква 2-phase commit protocol и ресурсите трябва да бъдат регистрирани и управлявани посредством протокола XA и Open XA стандарта.
Recovery from failure – мениджъра е отговорен за осигуряване на средствата да не се оставят трансакциите в състояния на несъответствия, ако има повреда в системата и приложението се срива.[2]
Model-View-Controller (MVC) е архитектурен модел за изграждане на потребителски интерфейси. Той разделя дадено софтуерно приложение на три взаимносвързани части, така че да се отделят вътрешни представяния на информация от начините, по които информацията се представя на потребителя/или от страна на потребителя: контролери, изгледи, модели. Както и при други софтуерни модели, MVC изразява „core of the solution“ на проблем, докато позволява да бъде адаптиран за всяка система. Специфични MVC архитектури могат да се различават значително.
Елементи: Централният елемент на MVC – The model моделът, улавя поведението на приложението по отношение на своя домейн, независимо от потребителския интерфейс. Моделът директно управлява данните, логиката и правилата на приложението. The view изгледът може да бъде всеки изход за представяне на информация, например чрез графика или диаграма; множество изгледи към една и съща информация са възможни, като стълбчета за управление и табличен изглед за счетоводители.
Третата част Controller контролера, приема входа от потребителя и го конвертира в команди за модела или изгледа.
Взаимодействия: В допълнение за разделяне на приложението на трите вида елементи, дизайн на model–view–controller определя взаимодействието между тях. The Controller – Контролерът може да изпраща команди към модела за актуализиране състоянието на модела (например, редактирането на документ). Той също може да изпраща команди към свързаната с изгледа част, за да се промени представянето на модела (например, чрез скролиране на документа).
The model – Моделът уведомява свързаните части с изгледа и контролера, когато е налице промяна в състоянието му. Това уведомяване позволява на изгледа да изведе на изхода актуалната информация и контролера да променя разположението на наборите от команди.
The view – Изгледа изисква информация от модела, който използва, за да се генерира изходната информация за представяне на потребителя.
Използване в уеб приложения: Въпреки че първоначално е разработен за настолните компютри Model-View-Controller е широко приет като архитектура за World Wide Web приложения в голяма част от езици за програмиране. Няколко търговски и нетърговски уеб приложения са създадени, които прилагат тази схемата. Тези приложения се различават по своите интерпретации, основно в начина, по който отговорностите им Model-View-Controller са разделени между клиента и сървъра.
По рано уеб MVC рамките поведоха с подход, който оставя почти цялата логика модел, изглед и контролер на сървъра. При този подход, клиентът изпраща или хипервръзки искания или форма вход към контролера и след това получава пълна и актуализирана уеб страница (или друг документ) от гледката; The model – модела съществува изцяло на сървъра.
Като клиентски технологии са създадени, рамки като AngularJS and Ember.js, JavaScriptMVC and Backbone са създадени за да позволят на елементите на MVC да изпълняват частично на машината на клиента.
История: MVC е едно от основните прозрения в началото на развитието на графични потребителски интерфейси, и един от първите подходи за описание и прилагане на софтуерни конструкции по отношение на техните отговорности. Trygve Reenskaug представя MVC в Smalltalk-76 по време на посещението на Xerox Parc през 1970 г.
През 1980, Jim Althoff и други приложени версия на MVC за Smalltalk-80 клас библиотеката. Едва по-късно, през 1988 г. в статия на списанието The Journal of Object Technology се подчертава, че MVC е изразена като основна идея в структурата на графично потребителският интерфейс.[3][4][5]
Spring's Remote Access framework е абстракция за работа с различни RPC – базирани технологии и е достъпен на Java платформата, както за свързаност на клиенти така и за разпределителни обекти на сървъри. Най-важната особеност, предлагана от този framework е лесната конфигурация и използване на тези технологии, колкото е възможно чрез комбиниране на инверсия на контрола и аспектно ориентираното програмиране AOP.
Този framework предвижда също пълно възстановяване при неизправности (автоматично повторно свързване след неуспешна връзка) и някои оптимизации за клиентската страна при използване на EJB remote stateless session beans. Spring осигурява поддръжка за тези протоколи и продукти от кутията:
Apache CXF осигурява интеграция със Spring framework за RPC стил за изваждане на обект от страна на сървъра.
Клиентските и сървърните настройки за всички протоколи RPC стил и продукти, поддържани от Spring Remote access framework (с изключение на поддръжката от страна на Apache Axis) са конфигурирани в Spring Core container.
Има алтернативно изпълнение с отворен код (Cluster4Spring) от подсистема за отдалечен достъп, включени в Spring framework която има за цел да подкрепи различни схеми за отдалечен достъп като (1 – 1, 1-many, dynamic services discovering).
Spring Batch framework е цялостно решение с цел да даде възможност за разработването на надеждни batch приложения, които често се срещат в съвременните enterprise системи. Spring Batch предоставя преизползваеми функции, които са от съществено значение при обработката на големи обеми от данни, включително:
Spring Batch framework предоставя също и по-усъвършенствани технически услуги и функции, които дават възможност за обработка на изключително голям обем от данни и висока производителност на batch задачите, чрез оптимизация и подразделения.
Spring Integration framework е framework с отворен код за интеграция на Enterprise приложения. Той предоставя възможност за разработването на интеграционни решения, типични за event-driven архитектури и messaging-centric архитектури.
Spring Integration предлага също поддръжка на pipe & filter архитектури.
Тази страница частично или изцяло представлява превод на страницата Spring Framework в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите.
ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни. |