스프링을 이해하려고합니다. 나는 그것에 대해 읽고 튜토리얼을 끝냈다. 저는 IoC 패러다임과 DI가 Spring에서 구현된다는 사실을 알게되었습니다.스프링을 사용하지 않을 때의 문제점
내 질문은 이것입니다. 스프링을 사용하지 않으면 무엇을 잃게됩니까? 나는 이것이 큰 질문이고 다소 주관적인 것이라고 생각한다. 그러나 스프링을 사용하지 않으면 몇 가지 점을 쓰거나 문제의 예를 들려 주면 저와 다른 많은 사람들에게 도움이 될 것이라고 생각합니다.
실제로 문제가 없습니다. 그러나 코드 작성을 시작하면 Spring과 같은 자체 개발 프레임 워크로 끝납니다. Spring을 사용하여 얻을 수있는 것은 프레임 워크가 이미 (자신보다) 일반화되어 있으며 많은 다른 프로젝트에서 사용할 수 있다는 것입니다. 그리고 가장 중요한 것은 (아마도) 많은 사용자들이 Spring을 잘 테스트하고 있다는 것입니다.
물론 봄뿐만 아니라 다른 프레임 워크를 사용해 볼 수도 있습니다. 거기에 제비가 있습니다 ...
glib 대답은 당신이 모든 것을 스스로 코딩해야한다는 것입니다. 나는 봄 (아직)에 대해 잘 모르겠지만, 봄에 두 개의 편집 점 필요로하는 반면, 심지어 생성자 주입의 기본 행위는 코드를 많이 필요 : 설정에서
:
<sectionGroup name="spring">
<section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
<section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</sectionGroup>
<spring>
<context>
<resource uri="config://spring/objects"/>
</context>
<objects xmlns="http://www.springframework.net">
<object name="mediaLibrary" type="AlbumLibraryWPF.AlbumLibrary, AlbumLibrary"/>
</objects>
</spring>
에서을 코드 :
IApplicationContext ctx = ContextRegistry.GetContext();
library = (Library)ctx.GetObject("mediaLibrary");
오히려 할 것이다 : 당신의 솔루션을 구축하는 DI 프레임 워크 자신이나 농축 쓰기?
스프링은 다른 IoC 도구 (DAO 관련 항목, 편리한 MVC 지원, 테스트 도구 ...)를 훨씬 능가합니다. 제 의견으로는 점차적으로 자바의 "맛"으로 성장했습니다. 그러나 요점은 아닙니다. IoC/DI에 대해 말하면, 사용하지 않는 것이 응용 프로그램에서 느슨한 결합을 얻는 가장 쉬운 방법 인 재사용 가능성과 관련이 있습니다. 분명히, 대부분의 사람들은 다른 프로젝트에서 구성 요소의 재사용 가능성을 생각하는 경향이 있습니다. 이는 내 경험에 비추어 볼 때 자주 발생하지는 않습니다. 재사용 성의 가장 큰 이점은 코드를 단위 테스트해야 할 때입니다. DI/IoC를 사용하여 및 인터페이스를 통해 프로그래밍하는 것은 unittest를 매우 쉽게 만들어 단위 테스트에 꺼려하는 사람들도 그것을 좋아할 것입니다.
UT와 관련하여 느슨한 커플 링과 이점이 있으면 잃을 것이 하나 있습니다.
IoC는 대부분 응용 프로그램이 성장하기 시작하고 모듈화/느슨한 결합을 위해 설계하지 않기 때문에 합리적인 경계가없는 많은 상호 연결된 클래스로 끝나기 때문에 IoC는 Java 언어에서 가장 좋은 점입니다.
스프링 및 기타 IoC/DI 프레임 워크는 처음부터 모듈화에 대해 생각하게합니다. 모듈 식/느슨하게 결합 된 코드를 사용하면 구성 요소 화 및 재사용이 훨씬 많아 지므로 단위 테스트를 더 잘 수행 할 수 있습니다 (단위 테스트를 수행하는 경우). 내가 DAO를 작성하려면
, 나는 앞까지의 인터페이스를 정의 할 수 있습니다
interface IPersonDao {
List<Person> getPersonsByTeam(String teamName);
}
을 한 후, 난 그냥 어디 봄 년대 SRC의에서이 인터페이스의 구현을 위해 호출 할 수 있습니다 "적용되고 ".내가 서비스 계층에서 그것을 필요로한다고 가정
class MyService {
@Autowired
IPersonDao svc;
}
또는 테스트 클래스에
을 :class TestPersonDao {
@Autowired
IPersonDao svc;
@Test
void testGetPersons(){
List<Person> persons = svc.getPersonsByTeam("billing");
Assert.assertDataSet(persons, "billing.xml");
}
}
게다가, 내 다오 구현이 다오 계약 덤비는없이 데이터 액세스의 복잡성을 숨길 수 있습니다. 나는 최대 절전 모드 세션 또는 지속성 관리자를 필요로하는 경우, 난 그냥 그 선언 : 클래스의
class JpaPersonDao implements IPersonDao {
@PersistenceContext
EntityManager em;
List<Person> getPersonsByTeam(String tm) {
em.createQuery("...");
}
}
컴포넌트 화는 협력 콩를 연결하기 위해 레지스트리를 필요로한다. 이것은 손으로 개발할 수 있지만 이미이를 수행하는 DI 프레임 워크가 있습니다. 게다가 Spring은 예외 변환, aspect 프로그래밍 지원, MVC 프레임 워크, 포틀릿 프레임 워크, hibernate, jpa 및/또는 다른 db 스택과의 통합과 같은 많은 것들을 많이 가지고있다. 물론 Spring IoC와 잘 어울린다.
스프링은 DI 프레임 워크를 훨씬 능가합니다. 이 당신을 위해 쉽게 프로그래밍이 더욱 지역의 많은 :
이 단지 몇 가지 예입니다 - 많은이 있습니다. 위의 것들을 사용할 필요는 없지만 성숙하고 잘 짜여진 프레임 워크의 모든 부분이 있으며, 일반적으로 일을 더 쉽게 만듭니다.
스프링 코어는 물론 의존성 주입입니다. DI 프레임 워크를 사용하면 얻을 수있는 이점은 소규모 프로젝트에서는 분명하지 않지만 크고 복잡한 프로젝트에서는 분명합니다. Martin Fowler는 Inversion of Control 매우 명확하게 설명합니다. 물론 다른 대안들 (예를 들어 Guice)은 그렇지만 Spring은 이제 산업 표준이라고 말할 수 있습니다.
사람들이 왜 의존성 주입 프레임 워크 (Spring과 Google Guice와 같은)를 사용하는지에 대한 글을 작성했습니다. 대부분의 자습서는 이것을 무시하지만 IMHO는 가장 중요한 것입니다.
이 문제를 이해하고 이러한 패턴/프레임 워크가 해결해야하는 문제가있을 때만 좋은 소프트웨어와 뛰어난 아키텍처를 선택할 수 있습니다. 여기에 대한
읽기 : http://www.redcode.nl/blog/2010/01/dependency-injection-dissection
간단히 말하면, 당신은 깨끗하고 검증 가능한 코드를 작성하기 위해 의존성 주입을 적용합니다. 또한 대가로 호출자는 호출 수신자가 호출하는 것이 아니라 구현 (주입)을 알고있는 디자인을 구현합니다 (이것이 "할리우드 원칙"으로 유명합니다). 이제 Spring과 Guice와 같은 DI 프레임 워크를 사용하지 않으면 공장을 사용하여 종속성 주입을 시도합니다. 그러나 공장은 테스트하는 동안 상용구 코드 및 불안정한 정리 비용을 수반합니다. 어떤 사람들은 Struts, Hibernate 등과 같은 다른 계층에 속한 프레임 워크와 쉽게 통합되는 이러한 프레임 워크에서 다른 강점을 발견합니다.
저는 Ruby on Rails 배경에서 Spring을 배우고 있으며 Spring이 해결하는 문제에 깊은 인상을 받았습니다. 그리고 Microsoft의 세계는 무엇입니까? 그들은 그러한 틀을 가지고 있습니까? NHibernate가 있지만 공식 NSpring이나 그런 계획이 있습니까? –
Spring.NET이라고합니다. 사용할 수있는 .NET IoC 프레임 워크가 많이 있습니다. – kgiannakakis