ASP.NET MVC - Чи повинна існувати бізнес-логіка в контролерах?

Дерік Вітакер пару днів тому опублікував статтю, в якій потрапив момент, про який я цікавився певний час: чи повинна існувати бізнес-логіка в контролерах?

Поки всі демонстраційні демонстраційні файли ASP.NET MVC я бачив, щоб у контролер входили доступ до репозиторію та бізнес-логіка. Деякі навіть кидають перевірку. Це призводить до отримання досить великих роздутих контролерів. Це справді спосіб використання рамки MVC? Здається, що це просто закінчиться безліччю дублюваних кодів та логіки, розкинутих на різних контролерах.

Ділова логіка дійсно повинна бути в моделі. Ви повинні орієнтуватися на жирні моделі, худі контролери.

Наприклад, замість того, щоб:

public interface IOrderService{
    int CalculateTotal(Order order);
}

Я вважаю за краще:

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

Це передбачає, що податок обчислюється зовнішньою службою і вимагає, щоб ваша модель знала про інтерфейси до ваших зовнішніх служб.

Це зробить ваш контролер таким чином:

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

Або щось подібне.

Мені подобається схема, представлена Microsoft Patterns & Practices . І я вірю в приказку "Картина варта тисячі слів".

Це захоплююче питання.

Я думаю, що цікавим є те, що велика кількість зразкових додатків MVC насправді не дотримується парадигми MVC у сенсі справжнього розміщення «бізнес-логіки» цілком у моделі. Мартін Фаулер зазначив, що MVC не є зразком у розумінні Gang Of Four. Швидше за все , це парадигма , що програміст повинен додати шаблони для , якщо вони створюють щось більше , ніж іграшка додатки.

Отже, коротка відповідь полягає в тому, що "бізнес-логіка" дійсно не повинна жити в контролері, оскільки контролер має додаткову функцію поводження з переглядом та взаємодією користувачів, і ми хочемо створювати об'єкти лише з однією метою.

Більш довга відповідь полягає в тому, що вам потрібно докласти певну думку до дизайну шару вашої моделі, перш ніж просто перейти логіку від контролера до моделі. Можливо, ви можете обробити всю логіку програми за допомогою REST, і в цьому випадку дизайн моделі повинен бути досить чітким. Якщо ні, то ви повинні знати, який підхід ви будете використовувати, щоб уникнути роздуття вашої моделі.

Ви можете перевірити цей дивовижний підручник Стівена Уолтера, який показує Проверку за допомогою службового шару .

Дізнайтеся, як перемістити логіку перевірки з дій контролера та в окремий сервісний рівень. У цьому навчальному посібнику Стівен Уолтер пояснює, як можна підтримувати різке розмежування проблем, ізолюючи службовий рівень від рівня контролера.

Бізнес-логіка не повинна міститися в контролерах. Контролери повинні бути максимально худими, в ідеалі слідкуйте за малюнком:

1. Знайти сутність домену
2. Закон про домен
3. Підготуйте дані для перегляду / повернення результатів

Крім того, контролери можуть містити певну логіку програми.

То де я можу ділову логіку? У моделі.

Що таке модель? Тепер це гарне питання. Будь ласка, перегляньте статтю «Шаблони та практики Microsoft» (чудово знайдіть AlejandroR). Тут є три категорії моделей:

• Модель перегляду : Це просто пакет даних, з мінімальною, якщо такою є, логікою для передачі даних з та в представлення, міститься основна перевірка поля.
• Модель домену : жирова модель з бізнес-логікою, працює на одній або декількох сукупностях даних (тобто сутність A у заданому стані, ніж дія на сутність B)
• Модель даних : модель, орієнтована на зберігання даних , логіка, що міститься в одному об'єкті, стосується лише цієї сутності (тобто, якщо поле a тоді поле b)

Звичайно, MVC - парадигма, яка надходить у різних різновидах. Я описую тут лише MVC, що займає верхній шар, дивіться цю статтю у Вікіпедії

Сьогодні MVC та подібні моделі-перегляд-презентатори (MVP) - це розділення моделей дизайну концернів, які застосовуються виключно до презентаційного шару більшої системи. У простих сценаріях MVC може представляти первинну конструкцію системи, потрапляючи безпосередньо в базу даних; однак у більшості сценаріїв контролер та модель в MVC мають слабку залежність від рівня обслуговування або рівня даних. Це все про архітектуру клієнт-сервер

Якщо ви використовуєте інжектори залежностей, ваша бізнес-логіка піде на них, отже, ви отримаєте акуратні та чисті контролери.