소프트웨어 아키텍처 패턴: MVC, MVVM,MVP

서론

소프트웨어 개발에서 아키텍처 패턴은 애플리케이션의 구조를 정의하고 각 구성 요소 간의 관계를 설정하는 중요한 역할을 합니다. 이 글에서는 가장 널리 사용되는 아키텍처 패턴인 MVC(Model-View-Controller)와 MVVM(Model-View-ViewModel)을 중심으로, 다양한 아키텍처 패턴들의 특징과 구조를 살펴보겠습니다. 모든 예제는 Java로 작성되어 있습니다.

1. MVC (Model-View-Controller) 패턴

MVC는 가장 오래되고 널리 사용되는 아키텍처 패턴 중 하나입니다.

구조

• Model: 데이터와 비즈니스 로직을 담당
• View: 사용자 인터페이스를 표현
• Controller: Model과 View 사이의 상호작용을 조정

동작 방식

1. 사용자가 View를 통해 상호작용합니다.
2. Controller가 사용자 입력을 받아 처리합니다.
3. Controller가 Model을 업데이트합니다.
4. Model이 변경되면 View에 알립니다.
5. View가 Model로부터 최신 데이터를 가져와 화면을 갱신합니다.

장점

• 관심사의 분리가 명확합니다.
• 코드 재사용성과 유지보수성이 높습니다.

단점

• 애플리케이션이 복잡해질수록 Controller가 비대해질 수 있습니다.

예제 코드 (Java)

// Model
public class User {
    private String name;

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
}

// View
public class UserView {
    public void printUserDetails(String userName) {
        System.out.println("User: " + userName);
    }
}

// Controller
public class UserController {
    private User model;
    private UserView view;

    public UserController(User model, UserView view) {
        this.model = model;
        this.view = view;
    }

    public void setUserName(String name) {
        model.setName(name);
    }

    public String getUserName() {
        return model.getName();
    }

    public void updateView() {
        view.printUserDetails(model.getName());
    }
}

2. MVVM (Model-View-ViewModel) 패턴

MVVM은 MVC의 변형으로, 주로 데이터 바인딩을 지원하는 프레임워크에서 사용됩니다.

구조

• Model: 데이터와 비즈니스 로직을 담당 (MVC와 동일)
• View: 사용자 인터페이스를 표현 (MVC와 동일)
• ViewModel: View와 Model 사이의 중재자 역할, View에 필요한 데이터와 명령을 제공

동작 방식

1. View는 ViewModel에 데이터 바인딩됩니다.
2. 사용자가 View와 상호작용하면, ViewModel이 이를 처리합니다.
3. ViewModel이 필요에 따라 Model을 업데이트합니다.
4. Model이 변경되면 ViewModel에 알립니다.
5. ViewModel이 관련 데이터를 업데이트하고, 바인딩된 View가 자동으로 갱신됩니다.

장점

• View와 Model의 분리가 명확합니다.
• 데이터 바인딩을 통해 View와 ViewModel의 동기화가 자동으로 이루어집니다.
• 단위 테스트가 용이합니다.

단점

• 간단한 UI에 대해서는 과도한 설계일 수 있습니다.
• 데이터 바인딩으로 인한 성능 문제가 발생할 수 있습니다.

예제 코드 (Java)

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;

// Model
public class User {
    private String name;

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
}

// ViewModel
public class UserViewModel {
    private User user;
    private PropertyChangeSupport support;

    public UserViewModel() {
        user = new User();
        support = new PropertyChangeSupport(this);
    }

    public String getName() {
        return user.getName();
    }

    public void setName(String name) {
        String oldName = user.getName();
        user.setName(name);
        support.firePropertyChange("name", oldName, name);
    }

    public void addPropertyChangeListener(PropertyChangeListener pcl) {
        support.addPropertyChangeListener(pcl);
    }
}

// View
public class UserView implements PropertyChangeListener {
    private UserViewModel viewModel;

    public UserView(UserViewModel viewModel) {
        this.viewModel = viewModel;
        this.viewModel.addPropertyChangeListener(this);
    }

    public void propertyChange(PropertyChangeEvent evt) {
        System.out.println("User name changed to: " + evt.getNewValue());
    }

    public void updateUserName(String name) {
        viewModel.setName(name);
    }
}

3. MVP (Model-View-Presenter) 패턴

MVP는 MVC의 변형으로, 주로 데스크톱 애플리케이션에서 사용됩니다.

구조

• Model: 데이터와 비즈니스 로직을 담당 (MVC와 동일)
• View: 사용자 인터페이스를 표현하며, 사용자 입력을 받습니다.
• Presenter: View와 Model 사이의 중재자 역할, View의 이벤트에 응답하고 Model을 조작합니다.

동작 방식

1. 사용자가 View와 상호작용합니다.
2. View는 Presenter에게 사용자 액션을 전달합니다.
3. Presenter가 필요에 따라 Model을 업데이트하고 결과를 받아옵니다.
4. Presenter가 View를 업데이트합니다.

장점

• View와 Model의 완전한 분리로 단위 테스트가 용이합니다.
• View가 더 수동적이어서 재사용성이 높아집니다.

단점

• Presenter가 복잡해질 수 있습니다.
• View와 Presenter 간의 1:1 관계로 인해 코드 중복이 발생할 수 있습니다.

예제 코드 (Java)

// Model
public class User {
    private String name;

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
}

// View Interface
public interface UserView {
    void setUserName(String name);
    String getUserInput();
}

// Concrete View
public class UserViewImpl implements UserView {
    @Override
    public void setUserName(String name) {
        System.out.println("Displaying user name: " + name);
    }

    @Override
    public String getUserInput() {
        return "User Input";  // In a real app, this would get input from UI
    }
}

// Presenter
public class UserPresenter {
    private User model;
    private UserView view;

    public UserPresenter(User model, UserView view) {
        this.model = model;
        this.view = view;
    }

    public void updateUserName() {
        String userName = view.getUserInput();
        model.setName(userName);
        view.setUserName(model.getName());
    }
}

결론

각 아키텍처 패턴은 고유한 장단점을 가지고 있으며, 프로젝트의 요구사항과 규모에 따라 적절한 패턴을 선택해야 합니다.

• MVC는 간단하고 직관적이어서 소규모 프로젝트나 웹 애플리케이션에 적합합니다.
• MVVM은 데이터 바인딩을 지원하는 프레임워크를 사용하는 복잡한 UI 애플리케이션에 적합합니다.
• MVP는 테스트 용이성이 중요한 데스크톱 애플리케이션에 적합합니다.

아키텍처 패턴을 선택할 때는 팀의 경험, 프로젝트의 복잡성, 유지보수 요구사항 등을 종합적으로 고려해야 합니다. 또한, 하나의 패턴만을 고집하기보다는 필요에 따라 여러 패턴의 장점을 결합하여 사용하는 것도 좋은 접근 방법입니다.

마지막으로, 아키텍처 패턴은 가이드라인일 뿐이며, 실제 구현 시에는 프로젝트의 특성에 맞게 유연하게 적용해야 한다는 점을 명심해야 합니다. 지속적인 리팩토링과 개선을 통해 더 나은 구조를 만들어가는 것이 중요합니다.