public class HomeController : Controller
{
private AppEntities db = new AppEntities();
И много методов (Action) которые работаеют с db.
Вопрос №1: Поскольку будет много обращений отразных клиентов, правильно ли использовать глобльную переменную в контроллере или лучше в каждом методе создавать новую переменную?
Вопрос №2: IIS и MVC и EF правильно организуют многпоточную работу с БД?
Вопрос №3: Поскольку бесплатные лицензии при подключении к IIS считаются анонимные подключения (те что не используют NT аутентификацию, используется аутентификация через Membership), то на счет подключений IIS к SQL — не ясно,
если используется аутентификация SQL Сервера это анонимное подключение?
Здравствуйте, Alexandr Sulimov, Вы писали:
AS>И много методов (Action) которые работаеют с db.
IMHO уже пошли не туда. И даже если EF рассматривать как DAL, то все равно не туда.
Action должен общаться с бизнес-логикой, а не с DAL. Описанное выше мне подсказывает, что у вас логика в контроллере. Вынесите её в отдельный слой (гуглите про трехслойную архитектуру).
AS>Вопрос №1: Поскольку будет много обращений отразных клиентов, правильно ли использовать глобльную переменную в контроллере или лучше в каждом методе создавать новую переменную?
По умолчанию — контроллер создается на каждый запрос каждого пользователя. Вывод сами сделаете?
AS>Вопрос №2: IIS и MVC и EF правильно организуют многпоточную работу с БД?
Здравствуйте, Doc, Вы писали:
Doc>IMHO уже пошли не туда. И даже если EF рассматривать как DAL, то все равно не туда. Doc>Action должен общаться с бизнес-логикой, а не с DAL.
Action в MVC это уровень Controller. Знание где хранятся данные, их получить, отсортировать и т.д. — это область Bussines Logic. Таким образом, написав в Action что-то вроде
public ActionResult Index()
{
IEnumerable<SomeData> items;
using (var db = new AppContext()) {
items = db.SomeData
.Where(d => d.Id == someId)
.OrderBy(d => d.RecDate)
.Take(10)
.ToList();
}
return this.View(items);
}
вы вносите Bussines Logic в Controller, что противоречит идеи MVC.
Здравствуйте, 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-ы, его использование можно оправдать разве что хорошо настроенной кодогенерацией.
Здравствуйте, 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 выглядят в просто переадресацией. Но опять же это цель и назначение контроллера, это позволяет отделить модель в самостоятельную сборку и легко тестировать её. А контроллеры и должны быть тупыми и простыми.
