Mockito.thenThrow() 주의사항!

Posted at 2021. 9. 25. 03:23 | Posted in Framework/Spring
반응형

예외를 던지도록하는 테스트를 할 때 Exception 안에 메시지를 활용할 경우 Exception.class 를 사용하지말 고 new Exception()을 사용하자.

 

일단 예외 클래스를 보자

/**
 * 이미 종료된 대회일 때 예외
 *
 * @author jammini
 */
public class AlreadyContestEndException extends BadRequestException {
    public AlreadyContestEndException() {
        super("이미 종료된 대회입니다.");
    }
}

 

서비스를 모킹해서 예외를 던지도록 할 것이다.

@WebMvcTest(ContestInfoApi.class)
class ContestInfoApiTest extends WebMvcBase {
    @MockBean
    private ContestService contestService;
    
    @Test
    void alreadyContestEnd() throws Exception {
        // when
        // AlreadyContestEndException.class
        when(contestService.modify(anyLong(), any())).thenThrow(AlreadyContestEndException.class);
        
        // ...
    }
    
 }

 

@ControllerAdvice 를 이용해 예외 클래스 안의 message 속성을 사용할 경우!

/**
 * 웹 예외 핸들러<br>
 * 시스템상에 발생하는 예외를 잡아서 공통으로 처리한다.
 *
 * @author antop
 */
@Slf4j
@RestControllerAdvice
public class ErrorAdvisor {

    /**
     * 400 Bad Request 예외 처리
     */
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(BadRequestException.class)
    ErrorMessage badRequest(Exception e) {
        log.debug("message = {}", e.getMessage());
        return ErrorMessage.badRequest(e.getMessage());
    }
    
  }

 

message는 null이 출력되게 된다. thenThrow() 인자로 new Exception() 을 사용하자.

when(contestService.modify(anyLong(), any())).thenThrow(new AlreadyContestEndException());

 

 

 

 

 

반응형

'Framework > Spring' 카테고리의 다른 글

Spring + @Lazy  (0) 2019.08.05
Twelve Best Practices For Spring XML Configurations  (0) 2010.06.23
//

Spring + @Lazy

Posted at 2019. 8. 5. 00:46 | Posted in Framework/Spring
반응형

https://github.com/antop-dev/spring-lazy

요즘 MSA를 공부하면서 아래와 같은 문구를 보았다.

마이크로서비스에서는 완전 자동화를 달성하기 위해 초소한의 시동/종료 시간을 갖도록 애플리케이션의 크기를 가능한 한 작게 유지하는 것이 극단적으로 아주 중요하다.
이를 위해 마이크로서비스에서는 객체와 데이터의 지연 로딩lazy loading에 대해서도 고려해봐야 한다.

이 때 떠오른 단어는 Spring과 @Lazy이다.

스프링 빈 설정시 @Lazy 애노테이션만 달아주면 이 빈을 가져오는 시점에 생성하기 때문에 모든 빈을 처음 초기화시에 만들지 않는다.

그런데 약간의 의문사항이 있어서 테스트 해봤다... 구글링을 대충 해도 나오는 자료이지만 직접 해봤다.

등장 클래스

아래와 같이 3개의 클래스를 빈으로 등록했다. 패턴은 다 같고 First, Second, Third 만 바뀐다.

@Component
public class First {
    @Autowired
    private Second second;

    public First() {
        System.out.println("first class constructor");
    }

    public void go() {
        System.out.println("Hello first!");
        second.go();
    }
}

테스트 코드는 아래와 같다.

public class LazyApplicationTests {
    @Test
    public void lazy() {
        ApplicationContext context = new AnnotationConfigApplicationContext(LazyApplication.class);
        System.out.println("call first.go()");
        First first = context.getBean(First.class);
        first.go();
    }
}

일반적인 빈 설정

먼저 위와 같이 @Lazy를 사용하지 않는 일반 적인 설정이다. 후에 스프링 컨텍스트에서 First 인스턴스를 꺼내서 go() 메서드를 수행할 것이다.

예상한 대로 빈이 전부 생성 된 후(①) FIrst.go() 이후의 작업이 수행된다(②).

first class constructor
second class constructor
third class constructor
Spring context loaded call
first.go()
Hello first!
Hello second
Hello third!

하지만 좀 이상한 점이 있는데 예상은 Thrid → Second → First 순으로 생성될 줄 알았지만 반대로 생성된다. 생성자를 사용하지 않고 @Autowired나 세터setter를 사용하면 스프링이 이 클래스를 까서(?) 적용을 하게 된다.

@Autowired를 사용하지 않고 생성자constructor를 사용하면 예상한 순서대로 빈이 만들어진다.

@Component
public class First {
    private final Second second;

    public First(Second second) {
        this.second = second;
        System.out.println("first class constructor");
    }

    public void go() {
        System.out.println("Hello first!");
        second.go();
    }
}
third class constructor second class constructor first class constructor Spring context loaded call first.go() Hello first! Hello second Hello third!

@Lazy 적용

첨부파일
다운로드

Thrid, Second, Fourth 는 스프링 초기화시 생성되고 First는 지연 로딩이 적용된다.

third class constructor
second class constructor
fourth class constructor
Spring context loaded
call first.go()
first class constructor
Hello first!
Hello second
Hello third!

동시성 concurrency

First 빈이 생성 되는데 3초가 걸린다고 가정해보자.

@Component
@Lazy
public class First {
    private final Second second;

    public First(Second second) {
        this.second = second;
        // 인스턴스를 생성하는데 3초가 걸린다.
        System.out.println("It takes 3 seconds to create an instance");
        try {
            for (int i = 0; i < 3; i++) {
                System.out.println((3 - i) + "..");
                Thread.sleep(1000);
            }
        } catch (InterruptedException e) {
            System.out.println(e.getMessage());
        }
        System.out.println("first class constructor");
    }

    public void go() {
        System.out.println("Hello first!");
        second.go();
    }
}

First 인스턴스를 사용하는 다른 인스턴스에서 동시에(거의 동시에?) 요청이 들어온다면?

테스트 코드는 아래와 같다.

@Test
    public void concurrency() throws Exception {
        ApplicationContext context = new AnnotationConfigApplicationContext(LazyApplication.class);
        System.out.println("Spring context loaded");

        for (int i = 0; i < 3; i++) {
            Thread thread = new Thread(() -> {
                System.out.println("call first.go()");
                First first = context.getBean(First.class);
                first.go();
            });

            thread.start();
            System.out.println(thread.getName() + " started.");
            Thread.sleep(100);
        }

        // 결과를 보기 위해 5초 대기
        Thread.sleep(5000);
    }

걱정과는 다르게 매우 잘 작동한다! 스프링 구욷!

third class constructor
second class constructor
fourth class constructor
Spring context loaded
Thread-2 started.
Thread-2 call first.go()
It takes 3 seconds to create an instance
3..
Thread-3 started.
Thread-3 call first.go()
Thread-4 started.
Thread-4 call first.go()
2..
1..
first class constructor
Thread-2 Hello first!
Thread-4 Hello first!
Thread-2 Hello second
Thread-4 Hello second
Thread-4 Hello third!
Thread-3 Hello first!
Thread-3 Hello second
Thread-3 Hello third!
Thread-2 Hello third!
반응형

'Framework > Spring' 카테고리의 다른 글

Mockito.thenThrow() 주의사항!  (0) 2021.09.25
Twelve Best Practices For Spring XML Configurations  (0) 2010.06.23
//

Twelve Best Practices For Spring XML Configurations

Posted at 2010. 6. 23. 11:48 | Posted in Framework/Spring
반응형
출처 : http://onjava.com/lpt/a/6443


스프링 XML Configuration을 위한 12가지 최선의 실천사항들

by Jason Zhicheng Li
01/25/2006

Spring is a powerful Java application framework, used in a wide range of Java applications. It provides enterprise services to Plain Old Java Objects (POJOs). Spring uses dependency injection to achieve simplification and increase testability.property name="shippedBy" value="lizjason Spring beans, dependencies, and the services needed by beans are specified in configuration files, which are typically in an XML format. The XML configuration files, however, are verbose and unwieldy. They can become hard to read and manage when you are working on a large project where many Spring beans are defined.

스프링은 Java 애플리케이션의 많은 범위에서 사용하고 있는 강력한 Java 애플리케이션 프레임워크입니다. 이것은 POJO(Plan Old Java Objects)에 엔터프라이즈 서비스의 힘을 제공합니다. 스프링은 간결함과 테스트 용이성을 이루기 위해 의존성 주입(dependency injection)을 이용합니다. 스프링 빈들과 의존성 그리고 빈들이 필요한 서비스들은 configuration 파일들에 설정하는데 일반적으로 XML 형식으로 되어 있습니다. 어쨌거나 이 XML configuration 파일들은 장황하고 다루기 쉽지 않습니다. 큰 프로젝트에서 스프링 빈을 많이 정의할 경우 이 configuration은 읽기도 어렵고 관리하기도 어려워집니다.

In this article, I will show you 12 best practices for Spring XML configurations. Some of them are more necessary practices than best practices. Note that other factors, such as domain model design, can impact the XML configuration, but this article focuses on the XML configuration's readability and manageability.

이 기사에서 스프링 XML configuration에 대한 12가지 최선의 실천사항들을 소개할 것입니다.  그 중 일부는 최선의 실천사항이라기 보다는 필수 실천사항들입니다. 도메인 모델 설계같은 다른 요소의 영향도 고려해야 하지만 이 기사에서는 configuration의 가독성(readability)과 관리편의성(manageablitity)에 초점을 두었습니다.


1. Avoid using autowiring
Spring can autowire dependencies through introspection of the bean classes so that you do not have to explicitly specify the bean properties or constructor arguments. Bean properties can be autowired either by property names or matching types. Constructor arguments can be autowired by matching types. You can even specify the autodetect autowiring mode, which lets Spring choose an appropriate mechanism. As an example, consider the following:

스프링은 빈의 introspection을 통해 의존관계를 자동으로 묶을(autowirie) 수 있어 명시적으로 빈의 프로퍼티나 생성자 아규먼트를 지정하지 않아도 됩니다. 프로퍼티 이름이나 타입 매칭으로 빈의 프로퍼티를 자동 설정할 수 있습니다. 타입 패칭으로 생성자의 아규먼트를 자동 설정할 수 있습니다. 또한 자동탐지를 autowiring 모드로 지정하여 스프링이 적절한 메커니즘을 선택하게 할 수 있습니다. 다음 예제를 보십시오.

<bean id="orderService" class="com.lizjason.spring.OrderService" autowire="byName"/>

The property names of the OrderService class are used to match a bean instance in the container. Autowiring can potentially save some typing and reduce clutter. However, you should not use it in real-world projects because it sacrifices the explicitness and maintainability of the configurations. Many tutorials and presentations tout autowiring as a cool feature in Spring without mentioning this implication. In my opinion, like object-pooling in Spring, it is more a marketing feature. It seems like a good idea to make the XML configuration file smaller, but this will actually increase the complexity down the road, especially when you are working on a large project where many beans are defined. Spring allows you mix autowiring and explicit wiring, but the inconsistency will make the XML configurations even more confusing.

컨테이너에서 OrderService 클래스의 프로퍼티 이름으로 빈 인스턴스를 매치하도록 사용하고 있습니다. Autowiring은 어쩌면 타이핑하는 수고를 줄이고 난잡함을 줄일 수 있습니다.  그러나 이것은 configuration의 명확성과 유지보수성을 희생하기에 실제 프로젝트에서 사용하면 안됩니다. 많은 튜토리얼과 프리젠테이션에서 이러한 숨겨진 영향을 언급하지 않고 스프링의 쿨한 특징으로 적극 추천하고 있습니다. 사견으로 스프링의 객체 풀링 같이 이것은 마케팅을 위한 특징에 가깝습니다. 이것은 XML configuration 파일을 작게 만드는 좋은 아이디어 같지만 실제로 복잡함을 증가시킬 것입니다. 특히 많은 빈들이 정의된 대규모 프로젝트에서 더합니다. 스프링에서 autowiring과 명시적인 wiring을 섞어서 쓸 수도 있지만 이러한 일관성 없는 방식은 XML configuration을 더욱 혼란스럽게 만듭니다.

2. Use naming conventions
This is the same philosophy as for Java code. Using clear, descriptive, and consistent name conventions across the project is very helpful for developers to understand the XML configurations. For bean ID, for example, you can follow the Java class field name convention. The bean ID for an instance of OrderServiceDAO would be orderServiceDAO.For large projects, you can add the package name as the prefix of the bean ID.

이것은 java 코드에서와 같은 사상입니다. 프로젝트 전반에 거쳐 명확함, 선언적 그리고 일관된 명명규칙을 사용하면 개발자들이 XML configuration을 이해하는데 많은 도움을 줍니다. 빈 ID로 예를 들자면 Java 클래스의 필드 이름 규칙을 사용할 수 있을 것입니다. OrderServiceDAO 인스턴스의 빈 아이디는 orderServiceDAO가 될 것입니다. 대규모 프로젝트에서는 빈 ID의 접두어로 패키지 이름을 추가할 수 있을 겁니다.

3. Use shortcut forms
The shortcut form is less verbose, since it moves property values and references from child elements into attributes. For example, the following:

프로퍼티 값이나 레퍼런스를 자식 엘리먼트에서 속성으로 옮기기에 간단한 형식이 덜 장황합니다. 아래 예를 보십시오.

    <bean id="orderService"
        class="com.lizjason.spring.OrderService">
        <property name="companyName">
            <value>lizjason</value>
        </property>
        <constructor-arg>
            <ref bean="orderDAO">
        </constructor-arg>
    </bean>

can be rewritten in the shortcut form as:

이것은 다음과 같이 간단한 형식으로 다시 작성할 수 있습니다. 

    <bean id="orderService"
        class="com.lizjason.spring.OrderService">
        <property name="companyName"
            value="lizjason"/>
        <constructor-arg ref="orderDAO"/>
    </bean>

The shortcut form has been available since version 1.2. Note that there is no shortcut form for <ref local="...">.

간단한 형식은 1.2 버전부터 사용이 가능합니다. <ref local="...">을 위한 간단한 형식은 없다는 것을 염두해 두십시오.

The shortcut form not only saves you some typing, but also makes the XML configuration files less cluttered. It can noticeably improve readability when many beans are defined in a configuration file.

간단한 형식은 타이핑을 줄이는 것뿐만 아니라 XML configuration 파일을 덜 난잡하게 해 줍니다. Configuration 파일에 많은 빈들을 정의할 경우 눈에 띄게 가독성을 향상시킬겁니다.

4. Prefer type over index for constructor argument matching
Spring allows you to use a zero-based index to solve the ambiguity problem when a constructor has more than one arguments of the same type, or value tags are used. For example, instead of:

스프링은 생성자가 두 개이상의 같은 타입을 가질 때 모호한 문제를 풀기 위해 0부터 시작하는 index를 사용하는 것을 허용합니다. 예를 들면 다음과 같습니다.

    <bean id="billingService"
        class="com.lizjason.spring.BillingService">
        <constructor-arg index="0" value="lizjason"/>
        <constructor-arg index="1" value="100"/>
    </bean>

It is better to use the type attribute like this:

이것은 다음과 같이 type 속성을 사용하는게 더 낫습니다.

    <bean id="billingService"
        class="com.lizjason.spring.BillingService">
        <constructor-arg type="java.lang.String"
            value="lizjason"/>
        <constructor-arg type="int" value="100"/>
    </bean>

Using index is somewhat less verbose, but it is more error-prone and hard to read compared to using the type attribute. You should only use index when there is an ambiguity problem in the constructor arguments.

index를 사용하는 것이 어느 정도 더 간결하지만 더 에러가 발생하기 쉽고 type 속성에 비해 읽기도 어렵습니다. 생성자 아규먼트에 모호한 문제가 있을 경우에만 index를 사용하여야 합니다.

5. Reuse bean definitions, if possible
Spring offers an inheritance-like mechanism to reduce the duplication of configuration information and make the XML configuration simpler. A child bean definition can inherit configuration information from its parent bean, which essentially serves as a template for the child beans. This is a must-use feature for large projects. All you need to do is to specify abstract=true for the parent bean, and the parent reference in the child bean. For example:

Configuration 정보의 중복을 줄이고 XML configuration을 간결하게 하기 위해 스프링은 상속과 비슷한 메커니즘을 제공합니다. 자식 빈 정의는 부모 빈으로부터 configuration 정보를 상속받을 수 있습니다. 부모 빈 정의가 자식 빈을 위한 템플릿 역할을 합니다. 대규모 프로젝트에서는 반드시 사용하여할 기능입니다. 해야 할 일은 단지 부모 빈에 abstract=true로 설정하고 자식 빈에서 parent 로 참조하는 것입니다. 예를 들어보면.

    <bean id="abstractService" abstract="true"
        class="com.lizjason.spring.AbstractService">
        <property name="companyName"
            value="lizjason"/>
    </bean>     <bean id="shippingService"
        parent="abstractService"
        class="com.lizjason.spring.ShippingService">
        <property name="shippedBy" value="lizjason"/>
    </bean>

The shippingService bean inherits the value lizjason for the companyName property from the abstractService bean. Note that if you do not specify a class or factory method for a bean definition, the bean is implicitly abstract.

shippingService 빈은 abstractService 빈으로 부터 lizjason 값을 가진 companyName 속성을 상속받습니다. 만일 빈 정의에 클래스나 팩토리 메소드를 지정하지 않는다면 그 빈은 암시적으로 abstract이 된다는 것을 알아두십시오.

6. Prefer assembling bean definitions through ApplicationContext over imports
Like imports in Ant scripts, Spring import elements are useful for assembling modularized bean definitions. For example:

Ant 스크립트의 import같이 스프링의 import 엘리먼트는 빈 정의를 모듈화하여 조립하는데 유용합니다. 예를 들면:

    <beans>
        <import resource="billingServices.xml"/>
        <import resource="shippingServices.xml"/>
        <bean id="orderService"
            class="com.lizjason.spring.OrderService"/>
    <beans>

However, instead of pre-assembling them in the XML configurations using imports, it is more flexible to configure them through the ApplicationContext. Using ApplicationContext also makes the XML configurations easy to manage. You can pass an array of bean definitions to the ApplicationContext constructor as follows:

그런데, import를 이용하여 XML configuration 안에서 미리 조립하는 대신 ApplicationContext 클래스를 이용하여 구성하는 것이 보다 유연합니다. 또한 ApplicationContext를 이용하면 XML configuration을 관리하기 쉬워집니다. 다음과 같이 빈 정의의 배열을 ApplicationContext 생성자에 전달할 수 있습니다.

    String[] serviceResources =
        {"orderServices.xml",
        "billingServices.xml",
        "shippingServices.xml"};
    ApplicationContext orderServiceContext = new
        ClassPathXmlApplicationContext(serviceResources);


7. Use ids as bean identifiers
You can specify either an id or name as the bean identifier. Using ids will not increase readability, but it can leverage the XML parser to validate the bean references. If ids cannot be used due to XML IDREF constraints, you can use names as the bean identifiers. The issue with XML IDREF constraints is that the id must begin with a letter (or one of a few punctuation characters defined in the XML specification) followed by letters, digits, hyphens, underscores, colons, or full stops. In reality, it is very rare to run into the XML IDREF constraint problem.

빈 식별자로 id나 name을 지정할 수 있습니다. id를 사용하면 가독성을 향상시키지는 않지만 XML 파서가 빈 참조를 검사하는데 도움이 됩니다. XML IDREF 제약때문에 id를 사용할 수 없으면 빈 식별자로 name을 사용할 수 있습니다. XML IDREF 제약의 이슈는 id는 반드시 문자(또는 XML 스펙에 정의된 구두문자 중 하나)로 시작하여 뒤에 문자, 숫자, 하이픈, 밑줄, 콜론 또는 마침표가 옵니다. 사실, XML IDREF 제약의 문제에 빠지는 것은 매우 드문 일입니다.

8. Use dependency-check at the development phase
You can set the dependency-check attribute on a bean definition to a value other than the default none, such as simple, objects, or all, so that the container can do the dependency validation for you. It is useful when all of the properties (or certain categories of properties) of a bean must be set explicitly, or via autowiring

빈 정의에 dependency-check 속성을 기본값인 none 이나, simple, object 또는 all로 설정할 수 있습니다. 이는 dependency를 검증해 줍니다. 명시적으로든 자동(autowiring)으로 든  빈의 모든 속성(또는 속성의 어떤 카테고리들)에 반드시 값이 설정되어야 할 때 유용합니다.

    <bean id="orderService"
        class="com.lizjason.spring.OrderService"
        dependency-check="objects">
        <property name="companyName"
            value="lizjason"/>
        <constructor-arg ref="orderDAO"/>
    </bean>

In this example, the container will ensure that properties that are not primitives or collections are set for the orderService bean. It is possible to enable the default dependency check for all of the beans, but this feature is rarely used because there can be beans with properties that don't need to be set.

이 예제에서 컨테이너는 기본 타입(primitive)이나 집합 타입이 아닌 orderService 빈의 속성 값은 설정될 것을 보장합니다. 기본으로 모든 빈에 dependency 검사를 하도록 할 수도 있지만, 반드시 설정할 필요가 없는 빈의 속성도 있을 수 있기 때문에 이 기능은 거의 사용하지 않습니다.

9. Add a header comment to each configuration file
It is preferred to use descriptive ids and names instead of inline comments in the XML configuration files. In addition, it is helpful to add a configuration file header, which summarizes the beans defined in the file. Alternatively, you can add descriptions to the description element. For example:

XML configuration 파일 중간에 주석을 다는 것보다는 딱 봐도 알 수 있는(descriptive) id나 이름을 사용하는 것이 더 좋습니다. 거기에다 파일의 헤더에 빈 정의에 대한 요약을 다는 것도 많은 도움이 됩니다.
대신 다음과 같이 description 엘리먼트로 설명을 추가할 수도 있습니다.

    <beans>
        <description>
            This file defines billing service
            related beans and it depends on
            baseServices.xml,which provides
            service bean templates...
        </description>
        ...
    </beans>

One advantage of using the description element is that it is easy to for tools to pick up the description from this element.

이 description 엘리먼트를 사용하면 각종 도구에서 설명을 뽑아내기 쉬운 장점이 있습니다.

10. Communicate with team members for changes
When you are refactoring Java source code, you need to make sure to update the configuration files accordingly and notify team members. The XML configurations are still code, and they are critical parts of the application, but they are hard to read and maintain. Most of the time, you need to read both the XML configurations and Java source code to figure out what is going on.

Java 소스 코드를 리팩토링할 때 관련된 configuration 파일들을 갱신할 필요가 있으면 팀 동료에게 알려야 합니다. XML configuration 역시 코드이며 애플리케이션에서 중요한 요소 중 하나이지만 읽기도 어렵고 유지하기도 어렵습니다. 대부분의 시간동안 뭐가 어떻게 돌아가는지 파악하기 위해 XML configuration과 Java 코드 둘 다 읽어야 할 필요가 있습니다.

11. Prefer setter injection over constructor injection
Spring provides three types of dependency injection: constructor injection, setter injection, and method injection. Typically we only use the first two types.

스프링은 생성자 주입, setter 주입 그리고 메소드 주입 세 가지 의존성 주입(dependency injection) 방법을 제공합니다. 전형적으로 앞의 두 가지 방식만 사용합니다.

    <bean id="orderService"
        class="com.lizjason.spring.OrderService">
        <constructor-arg ref="orderDAO"/>
    </bean>

    <bean id="billingService"
        class="com.lizjason.spring.BillingService">
        <property name="billingDAO"
            ref="billingDAO">
    </bean>


In this example, the orderService bean uses constructor injection, while the BillingService bean uses setter injection. Constructor injection can ensure that a bean cannot be constructed in an invalid state, but setter injection is more flexible and manageable, especially when the class has multiple properties and some of them are optional.

이 예제에서 orderService 빈은 생성자 주입을 사용한 반면 billingService는 setter 주입을 사용합니다. 생성자 주입의 경우 올바르지 않은 상태로는 생성할 수 없도록 보증하지만 setter 주입이 보다 유연하고 관리하기 쉽습니다. 특히 클래스가 여러 개의 속성을 가지고 그 중 몇 개는 선택적일 경우 더욱 그렇습니다.

12. Do not abuse dependency injection
As the last point, Spring ApplicationContext can create Java objects for you, but not all Java objects should be created through dependency injection. As an example, domain objects should not be created through ApplicationContext. Spring is an excellent framework, but, as far as the readability and manageability are concerned, the XML-based configuration can become an issue when many beans are defined. Overuse of dependency injection will make the XML configuration more complicated and bloated. Remember, with powerful IDEs, such as Eclipse and IntelliJ, Java code is much easier to read, maintain, and manage than XML files!

마지막으로, 스프링 ApplicationContext 는 여러분을 위해 Java 객체를 생성해 줍니다. 그러나 모든 Java 객체가 의존성 주입을 통해 생성해야 하는 것은 아닙니다. 그 예로 도메인 객체는 ApplicationContext를 통해 생성하지 말아야 합니다. 스프링은 뛰어난 프레임워크이나 많은 빈들이 정의되면 XML 기반의 configuration이 이슈가 될 수 있으므로 어느 정도 가독성과 관리성을 고려해야 합니다. 의존성 주입을 과용하면 XML configuration은 보다 복잡해지고 비대해질 것입니다. Eclipse나 InteliJ와 같은 강력한 IDE를 사용하면 Java 코드가 XML 파일보다 훨씬 읽거나 유지하거나 관리하기가 쉽다는 것을 기억하십시오!

Conclusion
XML is the prevailing format for Spring configurations. XML-based configuration can become verbose and unwieldy when many beans are defined. Spring provides a rich set of configuration options. Appropriately using some of the options can make the XML configurations less cluttered, but other options, like autowiring, may reduce readability and maintainability. Following good practices discussed in the article may help you to create clean and readable XML configuration files!

XML은 일반적인 Spring configuration 포맷입니다. 많은 빈들을 정의할 경우 XML 기반 configuration은 장황해지고 다루기 어려워지기 쉽습니다. 스프링은 풍부한 configuration 옵션들을 지원합니다. 적절히 이 옵션들을 사용하면 XML configuration은 덜 복잡해지기도 하지만 autowiring 같은 다른 옵션들은 가독성이나 관리성을 떨어뜨립니다. 이 기사에서 논의한 좋은 실천사항들을 따른다면 깨끗하고 가독성이 좋은 XML configuration 파일들을 만드는데 도움이 될 것입니다!

Resources
The weblog post this article is based upon
The Spring framework website for further information about Spring XML configurations
The XML specification for IDREF constraints

Jason Zhicheng Li is a senior software engineer with Object Computing, Inc. in St. Louis, MO. 
반응형
저작자표시

'Framework > Spring' 카테고리의 다른 글

Mockito.thenThrow() 주의사항!  (0) 2021.09.25
Spring + @Lazy  (0) 2019.08.05
//

티스토리툴바