Здравствуйте, mrozov, Вы писали:

M>Вы никогда не замечали, что в MVC есть буква M, но нет буквы "Bussines Logic"?

Все верно. Теперь уточним что есть M. Это данные и операции над ними (возьму описание из Wiki — The model consists of application data and business rules). Т.е. Bussines Logic как раз в данном случае входит в понятие модели.

Т.е. согласитесь, что в вашем примере с return db.Customers.Single(c=>c.CustomerID == custId) уже нарушено определение MVC.

Кроме того, такой строки в контроллере не будет. Будет что-то вроде return this.View(db.Customers....); И что из этого следует?

1) Усложняется тестирование этой самой Bussines Logic. Вместо метода, возвращающего список, вам надо тестировать данные зашитые во View.

2) А что если 2 или более разных View требуют один и тот же набор данных? Например для разных клиентов в разных форматах (html, json, xml). Вы напишите несколько дублей кода или метод. Первое приведет к усложенению сопровождения, второе — по сути начало создания BL слоя.

В общем, вспомните вообще зачем нужен MVC. Ну кроме модной строчки в резюме

M>Это НЕ бизнес-логика. Бизнес-логика, это нечто совсем иное.

А что?

M>И именно для такой логики (и подобной ей) в модели MVC и выделена отдельная сущность Controller, связывающая отображение с моделью.

Вот именно связывающая, а не "вычисляющая".

M>В противном же случае ваш контроллер вырождается в прокси к одноимённым BL-методам.

Вот тут согласен — в случаях простых сайтов зачастую Action выглядят в просто переадресацией. Но опять же это цель и назначение контроллера, это позволяет отделить модель в самостоятельную сборку и легко тестировать её. А контроллеры и должны быть тупыми и простыми.