DotNet
객체지향 프로그래밍 (OOP)
OOP 설계
아키텍처 패턴
MVC 패턴

MVC 패턴

MVC 패턴이란?

MVCModel-View-Controller 패턴은 소프트웨어 시스템을 세 가지 주요 컴포넌트인 Model, View, Controller로 나누어, 사용자 인터페이스UI와 비즈니스 로직을 분리하는 아키텍처 패턴입니다. 이 패턴은 특히 웹 애플리케이션이나 데스크탑 애플리케이션에서 자주 사용되며, 각 컴포넌트가 독립적으로 역할을 수행하여 유지보수성, 확장성을 높입니다.

MVC의 주요 컴포넌트

Model

Model은 애플리케이션의 데이터와 비즈니스 로직을 관리합니다. 데이터베이스와의 상호작용이나, 비즈니스 규칙을 처리하고, 변경된 데이터를 View와 Controller에게 알립니다.

View

View는 사용자가 볼 수 있는 UI를 담당하며, Model에서 제공한 데이터를 기반으로 화면을 렌더링합니다. View는 데이터에 대한 직접적인 로직을 포함하지 않으며, 그저 사용자가 볼 수 있는 UI를 표시하는 역할만 합니다.

Controller

Controller는 사용자 입력을 처리하고, 이를 Model에 전달하여 비즈니스 로직을 수행한 후 그 결과를 View로 전달합니다. Controller는 사용자로부터의 입력을 해석하고, 어떤 행동을 수행할지 결정하는 역할을 합니다.

MVC 패턴 구조

D2 Diagram

MVC 패턴 적용

MVC의 필요성

도서 관리 시스템에서 사용자가 도서를 검색하거나 대출할 수 있는 기능이 있다고 가정해봅시다. 이때 MVC 패턴을 적용하면 사용자 인터페이스와 도서 관리 로직을 명확히 분리할 수 있습니다. View는 도서의 목록을 화면에 표시하는 역할만 하고, Model은 도서 데이터와 관련된 비즈니스 로직을 담당하며, Controller는 사용자의 입력을 받아 그에 맞는 동작을 수행합니다.

잘못된 처리

MVC 패턴을 사용하지 않을 경우, 다음과 같은 문제가 발생할 수 있습니다:

public class BookManager
{
    public List<Book> books = new List<Book>();
    public void DisplayBooks()
    {
        foreach (var book in books)
        {
            Console.WriteLine(book.Title);
        }
    }
    public void SearchBooks(string title)
    {
        foreach (var book in books)
        {
            if (book.Title.Contains(title))
            {
                Console.WriteLine(book.Title);
            }
        }
    }
}
  • View와 Model의 결합: DisplayBooks 메서드는 데이터를 처리하면서 동시에 화면에 표시하는 역할을 합니다. 이는 View와 Model이 결합된 형태로, 이러한 코드 구조에서는 비즈니스 로직이 변경될 때 UI와 관련된 코드도 함께 수정해야 할 가능성이 높습니다.
  • 확장성의 문제: 애플리케이션이 복잡해질수록, 비즈니스 로직과 UI를 분리하지 않으면 유지보수가 어려워집니다.

MVC 패턴 적용 예시

MVC 패턴을 적용하여 위의 문제를 해결할 수 있습니다. 다음은 도서 관리 시스템에 MVC 패턴을 적용한 예시입니다.

// Model
public class Book
{
    public string Title { get; set; }
    public string Author { get; set; }
    public Book(string title, string author)
    {
        Title = title;
        Author = author;
    }
}
// View
public class BookView
{
    public void DisplayBooks(List<Book> books)
    {
        foreach (var book in books)
        {
            Console.WriteLine($"Title: {book.Title}, Author: {book.Author}");
        }
    }
    public void DisplayBookNotFound()
    {
        Console.WriteLine("No books found.");
    }
}
// Controller
public class BookController
{
    private List<Book> books;
    private BookView view;
    public BookController(List<Book> books, BookView view)
    {
        this.books = books;
        this.view = view;
    }
    public void SearchBooks(string title)
    {
        var foundBooks = books.Where(b => b.Title.Contains(title)).ToList();
        if (foundBooks.Any())
        {
            view.DisplayBooks(foundBooks);
        }
        else
        {
            view.DisplayBookNotFound();
        }
    }
}
// 클라이언트 코드
public class Program
{
    public static void Main(string[] args)
    {
        List<Book> books = new List<Book>
        {
            new Book("C# Programming", "Author A"),
            new Book("MVC Design Patterns", "Author B"),
            new Book("Clean Code", "Author C")
        };
        BookView view = new BookView();
        BookController controller = new BookController(books, view);
        controller.SearchBooks("Clean Code");
    }
}

MVC 구성 요소

Model

Book 클래스가 Model 역할을 담당하며, 도서의 데이터를 관리합니다. 데이터베이스나 비즈니스 로직을 처리할 수 있습니다.

View

BookView 클래스가 UI를 담당하며, 사용자에게 데이터를 표시합니다. Model에 있는 데이터를 기반으로 화면을 렌더링합니다.

Controller

BookController 클래스는 사용자의 입력을 받아 비즈니스 로직을 처리하고, 결과를 View에 전달합니다. Model과 View를 분리하여 서로 독립적으로 동작할 수 있도록 합니다.

장점

관심사의 분리

Model, View, Controller 각각이 서로 독립적으로 동작하므로, 관심사 분리를 통해 코드를 더 쉽게 유지보수할 수 있습니다. 예를 들어, UI가 변경되어도 비즈니스 로직을 수정할 필요가 없으며, 반대로 비즈니스 로직이 변경되어도 UI에 영향을 미치지 않습니다.

테스트 용이성

Controller와 Model이 View와 분리되어 있어, 비즈니스 로직과 데이터 처리 부분을 독립적으로 테스트할 수 있습니다. 이는 테스트 주도 개발TDD에서도 매우 유용합니다.

코드 재사용성

Model과 View를 분리함으로써 다양한 형태의 UIView를 추가할 수 있습니다. 예를 들어, 같은 도서 데이터를 사용해 웹 인터페이스나 모바일 인터페이스를 각각 별도로 구현할 수 있습니다.

한계

중복 코드 문제

MVC 패턴을 적용한 대규모 애플리케이션에서는 여러 View와 Controller가 비슷한 로직을 반복할 수 있습니다. 예를 들어, 비슷한 데이터를 처리하는 여러 Controller에서 중복된 코드가 발생할 수 있습니다. 해결방안은 다음과 같습니다.

  • 공통 로직을 별도의 서비스 계층으로 분리하여 재사용성을 높입니다.
  • View와 Controller 간의 데이터 처리 로직을 더 작은 단위로 나누어 모듈화합니다.

복잡한 데이터 흐름 문제

대규모 애플리케이션에서는 Model, View, Controller 간의 데이터 흐름이 복잡해질 수 있으며, 이는 디버깅과 유지보수를 어렵게 만듭니다. 다른 디자인 패턴을 조합하여 개선할 수 있습니다.

  • Observer 패턴을 적용하여 Model과 View 간의 데이터 변경 사항을 쉽게 추적합니다.
  • Mediator 패턴을 적용하여 Controller 간의 복잡한 상호작용을 간소화합니다.

성능 문제

대규모 애플리케이션에서 모든 뷰를 매번 렌더링하거나 많은 데이터 처리를 한 번에 수행하는 것은 성능 문제를 초래할 수 있습니다. 지연로딩, 캐싱등을 적용하여 개선할 수 있습니다.

  • 지연 로딩Lazy Loading을 통해 필요할 때만 데이터를 불러옵니다.
  • 캐싱을 사용하여 자주 사용되는 데이터를 미리 저장해, 불필요한 요청을 줄입니다.

적용 시 유의 사항

복잡성 증가

MVC 패턴을 적용하면 각 컴포넌트가 독립적으로 역할을 수행할 수 있지만, 시스템이 복잡해질수록 여러 컴포넌트를 관리하는 데 추가적인 복잡성이 생길 수 있습니다. 특히 작은 애플리케이션에서는 MVC 패턴이 필요 이상의 복잡성을 초래할 수 있습니다.

View와 Model 간의 간접 참조

MVC 패턴에서는 View와 Model이 직접 통신하지 않도록 해야 합니다. Controller를 통해 Model의 변경 사항을 View에 전달해야 하는데, 이를 제대로 관리하지 않으면 MVC 패턴의 의도와는 다르게 컴포넌트 간의 결합도가 높아질 수 있습니다.

객체지향 원칙과의 관계

단일 책임 원칙

MVC 패턴은 각 컴포넌트가 자신만의 책임을 갖도록 설계되어 있습니다. Model은 데이터를 관리하고, View는 UI를 담당하며, Controller는 사용자의 입력을 처리하는 역할을 합니다. 이를 통해 각 컴포넌트가 자신의 역할에만 집중할 수 있어 단일 책임 원칙SRP을 잘 준수합니다.

개방_폐쇄 원칙

MVC 패턴에서는 새로운 UI를 추가하거나 비즈니스 로직을 확장할 때 기존의 코드를 수정하지 않고도 확장할 수 있습니다. 예를 들어, 새로운 View를 추가할 때 Model이나 Controller를 변경하지 않고도 적용할 수 있으므로 개방-폐쇄 원칙OCP을 잘 따릅니다.

캡슐화

MVC 패턴에서는 Model, View, Controller 각각이 독립적으로 동작하며, 자신의 상태와 동작을 캡슐화Encapsulation합니다. 이를 통해 서로의 내부 구현에 의존하지 않고 상호작용할 수 있습니다.

다형성

MVC 패턴에서 Controller는 다양한 View와 상호작용할 수 있으며, View와 Model의 변경에 유연하게 대처할 수 있습니다. 다형성Polymorphism을 통해 서로 다른 UI 형태에 맞게 시스템을 확장할 수 있습니다.

맺음말

MVC 패턴은 애플리케이션의 구성 요소를 명확히 분리하여 유지보수성, 확장성을 높이는 데 매우 유용한 아키텍처 패턴입니다. 특히, UI와 비즈니스 로직을 분리하여 관심사 분리를 실현할 수 있으며, 테스트와 확장성 측면에서도 장점을 제공합니다.

심화 학습

MVP 패턴

MVPModel-View-Presenter 패턴은 MVC의 변형 중 하나로, View와 Controller 사이의 의존성을 줄이기 위해 등장했습니다. Presenter는 View에 더욱 밀접하게 연결되어, 비즈니스 로직을 처리하고 View를 업데이트하는 역할을 합니다. 이 패턴은 특히 웹 애플리케이션과 데스크탑 애플리케이션에서 많이 사용됩니다.

MVP 패턴의 구조

D2 Diagram

  • Model: 애플리케이션의 데이터와 비즈니스 로직을 관리.
  • View: UI 요소를 담당하며, Presenter와 연결되어 데이터를 표시.
  • Presenter: View와 Model 사이에서 중재자 역할을 하며, 비즈니스 로직을 처리한 후 View를 업데이트.

예시 

public interface ILibraryView
{
    void DisplayBooks(List<Book> books);
}
public class LibraryPresenter
{
    private ILibraryView _view;
    private LibraryService _service;
    public LibraryPresenter(ILibraryView view, LibraryService service)
    {
        _view = view;
        _service = service;
    }
    public void LoadBooks()
    {
        var books = _service.GetAllBooks();
        _view.DisplayBooks(books);
    }
}

MVP 패턴에서는 Presenter가 View와 Model을 모두 알고 있으며, 데이터를 직접적으로 View에 전달합니다.

MVVM 패턴

MVVMModel-View-ViewModel 패턴은 주로 WPFWindows Presentation Foundation와 같은 UI 프레임워크에서 사용됩니다. ViewModel은 View와 Model 사이의 중간층으로, View와 Model 사이의 데이터 바인딩을 통해 더 강력한 데이터 흐름을 지원합니다. 이는 특히 UI와 데이터 간의 상호작용이 많은 애플리케이션에서 유용합니다.

MVC와 마이크로서비스

MVC 패턴은 UI와 비즈니스 로직을 분리하여 유지보수성을 높이는 패턴이며, 마이크로서비스 아키텍처는 서비스 단위로 기능을 분리해 독립적인 배포와 확장성을 제공합니다. 이 두 패턴을 결합하면, 각 서비스가 MVC 구조로 동작하면서 마이크로서비스 간의 독립성을 유지할 수 있습니다.

통합의 주요 개념

  • 독립적인 서비스: 각 마이크로서비스는 하나의 MVC 구조로 구현됩니다. 예를 들어, User Service는 사용자 정보를 처리하는 Model, View, Controller를 각각 가지고 있습니다.
  • API Gateway: 클라이언트가 여러 마이크로서비스에 직접 접근하지 않고, API Gateway를 통해 통합된 인터페이스로 접근합니다. 이 방식은 마이크로서비스 간의 통신을 관리하는 데 유용합니다.
  • 비동기 통신: 서비스 간 통신에서 작업 큐나 메시징 시스템을 사용하여 비동기적으로 데이터를 처리하고, 부하를 분산할 수 있습니다.

간단한 예시: 도서 관리 시스템

  • UserController, UserService, UserView로 구성된 사용자 관리 마이크로서비스
  • BookController, BookService, BookView로 구성된 도서 관리 마이크로서비스
  • API Gateway는 사용자와 도서 정보를 통합하여 제공
// API Gateway
public class LibraryGateway
{
    private readonly UserController _userController;
    private readonly BookController _bookController;
    public LibraryGateway(UserController userController, BookController bookController)
    {
        _userController = userController;
        _bookController = bookController;
    }
    public void DisplayUserAndBookDetails(int userId, int bookId)
    {
        _userController.GetUser(userId);
        _bookController.GetBook(bookId);
    }
}

이 코드는 사용자가 특정 도서를 대출할 수 있도록 사용자와 도서 정보를 API Gateway를 통해 통합하는 과정입니다. 각 서비스는 독립적으로 작동하며, API Gateway가 두 서비스를 연결해줍니다.

결론

  • 서비스 독립성: 각 마이크로서비스는 MVC 구조로 동작하며, UI와 비즈니스 로직이 분리되어 확장성과 유지보수성이 향상됩니다.
  • API Gateway: 여러 서비스의 데이터를 통합해 클라이언트에 제공하며, 서비스 간 통신을 관리합니다. 이 방식은 마이크로서비스 환경에서 모듈성을 유지하면서도 MVC 패턴의 장점을 극대화하는 방식으로, 대규모 시스템에서 유용하게 사용됩니다.
Buy me a coffee Buy me a coffee
Producer-Consumer 패턴MVVM 패턴