Я постепенно конвертирую классический ASP-сайт в ASP.Net MVC. В моей папке Модификации я разделил ее на Business Objects (BO), Business Logic (BLL) и уровень доступа к данным (DAL) для 3-уровневой архитектуры в рамках моделей. Кажется, что это хорошо работает до сих пор в отношении операций с базой данных, и это держит мои контроллеры тощими. Например, типичный контроллер будет выглядеть следующим образом:Skinny Controller для загрузки файлов ASP.NET MVC
public ActionResult Index()
{
UserName UserDetails = UserManager.GetUserName();
CarrierList CarrierList = CarrierManager.GetCarrierList();
return View(new CarrierViewModel(CarrierList, UserDetails));
}
В основном я просто использовать контроллер передать функцию на слой BLL, который в свою очередь взаимодействует с BO слоями DAL &.
Где я смущен, это правильное место для логики, связанной с операциями без базы данных, такими как загрузка файлов. Например, я в настоящее время пишу код для загрузки файла Excel и импорта его содержимого в таблицу базы данных. Если бы я был следовать по той же схеме выше, мой контроллер должен содержать только функцию передать запрос на загрузку файлов на слой BLL так:
[HttpPost]
public ActionResult Index(HttpPostedFileBase file)
{
FileManager.ImportExcel(file);
return RedirectToAction("Index");
}
Проблема заключается в том, что каждый учебник или пример, который я вижу для загрузки файлов и Excel манипулируют своим файлом и кодом Excel непосредственно в контроллере. например here. Даже сообщение Скотта Ханзельмана here, по-видимому, подразумевает, что в порядке, чтобы положить логику загрузки файлов в контроллер.
Мой вопрос, учитывая мою 3-уровневую архитектуру ASP.NET MVC и толстую модель/тонкую цель проектирования контроллера, я нахожусь на правильном пути, выгружая логику обработки загрузки и Excel в модель BLL? Это похоже на то, что я пытаюсь сделать, но поскольку все примеры, которые я вижу в Интернете, просто помещают логику манипуляции с файлами в контроллер, я чувствую, что я иду против зерна.
Почему это не хорошая идея иметь BLL в MVC? Я основывал свой подход на [этом] (http://www.mikesdotnetting.com/Article/132/ASP.NET-MVC-is-not-all-about-Linq-to-SQL). Одна вещь, о которой я могу думать, это то, что ваши предложения по отдельным библиотекам классов предоставят себе лучшее повторное использование кода для консольного приложения, которое идет с этим сайтом. –
Точно. В качестве дополнительного бонуса он также заставит вас не делать обратные вызовы (например, от вашего DAL до вашего BLL). – Kenneth
В реальном сценарии я даже предпочитаю иметь ВСЕ мой код вне проекта MVC. Контроллеры и модель также должны идти в презентационном слое, а не в пользовательском интерфейсе. – Kenneth