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

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

M>>Кому должен?

Doc>Тому у кого занимал. Да еще с процентами.

Doc>Action в MVC это уровень Controller. Знание где хранятся данные, их получить, отсортировать и т.д. — это область Bussines Logic. Таким образом, написав в Action что-то вроде
...
Doc>вы вносите Bussines Logic в Controller, что противоречит идеи MVC.

ИМХО

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

Так вот, когда вы вместо того, чтобы написать return db.Customers.Single(c=>c.CustomerID == custId), начинаете писать что-нибудь вроде return new CustBl().GetCustomer(custId), а в CustBl.GetCustomer, ясное дело, return new CustDAL().GetCustomer(custId), то в большинстве случаев вы платите проценты чужому дяде запросто так. Без всякого смысла. Совсем. Эти вложения никогда не окупятся. В лучшем случае, вы, со временем, их вернёте. В худшем — потеряете насовсем.

Это НЕ бизнес-логика. Бизнес-логика, это нечто совсем иное. И именно для такой логики (и подобной ей) в модели MVC и выделена отдельная сущность Controller, связывающая отображение с моделью. В противном же случае ваш контроллер вырождается в прокси к одноимённым BL-методам.

Т.е., иными словами, ваш настоящий Controller спрятан внутри BL, "что противоречит идеи MVC".

Хотя спорить не стану — подход действительно очень распространённый. Но не очень эффективный. А для приложений, в которых 40% кода — это чистые (или почти чистые) crud-ы, его использование можно оправдать разве что хорошо настроенной кодогенерацией.