Skip to main content

1.1 Overview of Spring Framework — Origins and Philosophy

Welcome to the world of the Spring Framework, the absolute dominant force in global enterprise Java development and the foundational backbone of South Korea's e-Government Standard Framework.


🌱 1. Origins of the Spring Framework

In the early 2000s, the standard technology for building massive enterprise applications in Java was EJB (Enterprise JavaBeans).

The fundamental issue with EJB was its excruciating bloat and overwhelming complexity. Simply to build a basic function, developers were forced to inherit three or four interfaces and strictly deploy a heavy, lethargic container server environment. Amidst widespread frustration among developers, Rod Johnson published a concise book in 2002 ("J2EE Development without EJB") that directly criticized the nightmare of EJB. He proposed lightweight, practical framework code that received immense applause. This open-source code became the genesis of Spring. (The name "Spring" signifies the arrival of a fresh spring season after the traditional, heavy winter of J2EE.)

Core Philosophy: Abandon complex technological dependencies merely for the sake of technology! Return to the most fundamental form of Java programming—POJO (Plain Old Java Object)—allowing developers to focus 100% purely on business logic!

// The hellish code structure of the EJB era (severely tied to specific technologies)
public class OrderManagerBean implements SessionBean {
public void ejbCreate() throws CreateException { ... }
public void setSessionContext(SessionContext ctx) { ... }
// Framework requirement code is longer than the actual business logic!
}

// The perfect POJO pursued by the Spring Framework (the purest form of Java)
public class OrderService {
public void createOrder(Order order) {
// Only pure business logic exists, without complex inheritance or specific class implementations!
}
}

🛠️ 2. The 3 Core Programming Models Governing Spring

The Spring Framework is not just a mere collection of generic functionalities. It strictly enforces the best object-oriented architecture imaginable in Java, naturally guiding developers to breathe and utilize the following three core philosophies.

① IoC/DI (Inversion of Control and Dependency Injection)

Inside the Java code, developers do not manually carve out (new) and connect objects themselves. By simply declaring, "I need component B," Spring (a massive Lego assembler) automatically pierces and injects the requested component (Bean) from the outside. Application flexibility and the ability to seamlessly swap components undergo revolutionary liberation.

// [Past Traditional Approach] Developer holds explicit control
public class MemberService {
// If you want to switch from MySQLRepository to OracleRepository, you must directly rewrite the code.
private MemberRepository repository = new MySQLMemberRepository();
}

// [Spring IoC/DI Approach] Control is surrendered to Spring
@Service
public class MemberService {
private final MemberRepository repository;

// By merely exposing the constructor parameters, the Spring container automatically fills in the most appropriate DB storage component at runtime.
public MemberService(MemberRepository repository) {
this.repository = repository;
}
}

② AOP (Aspect-Oriented Programming)

Common, repetitive auxiliary logic (Cross-Cutting Concerns) like logging, transaction management, and authorization checks—which conventionally copy-paste 3~4 identical lines at the top and bottom of every single class—are completely surgically extracted. They are constructed as separate, dedicated files (Aspects) and seamlessly attached before and after the target core logic.

// [Before AOP] Defensive barrier code (Red) is longer than the core business logic (Blue)
public void transferMoney(Long fromId, Long toId, int amount) {
long startTime = System.currentTimeMillis(); // Common Log
Transaction tx = db.beginTransaction(); // Common Log
try {
// -------- CORE BUSINESS LOGIC ---------
accountDao.deduct(fromId, amount);
accountDao.add(toId, amount);
// --------------------------------------
tx.commit(); // Common Log
} catch (Exception e) {
tx.rollback(); // Common Log
} finally {
System.out.println("Time elapsed: " + (System.currentTimeMillis() - startTime)); // Common Log
}
}

// [After AOP] A single Spring @Transactional annotation instantly isolates all cross-cutting concerns!
@Transactional
@LogExecutionTime
public void transferMoney(Long fromId, Long toId, int amount) {
// Focus purely on explicit business execution
accountDao.deduct(fromId, amount);
accountDao.add(toId, amount);
}

③ PSA (Portable Service Abstraction)

Spring radically champions the 'Adapter' paradigm. Developers are never required to violently tear apart their code just because they switch Servlet specifications or distinct database implementations. As long as developers adhere to the consistent interface backbone provided by Spring, they can seamlessly swap out the underlying implementations—such as migrating from MyBatis to JPA, or tearing out an external library—while preserving the core business logic code with absolute safety.


🎯 3. Pro Tips for Modern Practical Engineering

💡 Understanding the Fundamental Difference: Library vs Framework

  • Library: A specialized utility knife that developers actively call and utilize whenever they specifically desire. The overarching control mechanism remains entirely with the developer themselves. (e.g., Jackson, Apache Commons)
  • Framework: A paradigm where you toss your freshly constructed Java files (components) entirely onto a massive, automated factory conveyor belt. The framework dictatorially enforces the rules of flow control; the entity invoking your code and explicitly managing its creation/destruction lifecycle is the framework itself. You must never forget the cardinal rule: Spring totally absorbs your classes into its IoC Container, ruthlessly seizing absolute control over their lifecycle!