Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.
31. Паттерн MVC
«Расскажите, что такое паттерн MVC и как вы его реализовали в своих проектах? Приведите пример того, как вы использовали MVC.»
Хороший ответ
Паттерн MVC (Model-View-Controller) — это принцип проектирования, который разделяет приложение на три взаимосвязанных компонента. Такое разделение помогает управлять сложностью, способствует организации кода и поддерживает масштабируемость:
1. Модель - слой данных и бизнес-логики приложения. Она отвечает за хранение данных, их обработку и определение бизнес-правил.
2. Представление - обрабатывает отображение данных, получая модель от контроллера. Оно только отображает информацию пользователю и отправляет команды пользователя контроллеру.
3. Контроллер - выступает в качестве посредника между моделью и представлением, получая данные из модели и решая, какое представление отображать.
В своих проектах я использовал паттерн MVC, чтобы обеспечить надлежащее разделение задач, что упрощает поддержку и расширение приложения. Например:
// Модель
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
}
// Контроллер
public class ProductsController : Controller
{
private readonly IProductRepo _repo;
public ProductsController(IProductRepo repo)
{
_repo = repo;
}
public async Task<IActionResult> Index()
{
var products = await _repo.GetAllAsync();
// Передаём модель в представление
return View(products);
}
}
// Представление (Index.cshtml)
@model IEnumerable<Product>
<h2>Продукты</h2>
<ul>
@foreach(var product in Model)
{
<li>@product.Name - $@product.Price</li>
}
</ul>
В этом примере ProductsController получает данные о продуктах, используя репозиторий IProductRepo, который абстрагирует логику доступа к данным. Полученные данные затем передаются в представление Index, которое отвечает за отображение информации о продуктах. Такое разделение позволяет вносить изменения в модель БД или бизнес-логику, не затрагивая логику представления, и наоборот, тем самым соблюдая принцип единственной ответственности.
Такой подход не только делает архитектуру яснее, но и повышает тестируемость приложения. Каждый компонент может быть протестирован независимо, что крайне важно для поддержания высокого качества кода по мере масштабирования приложения.
Часто встречающийся плохой ответ
«MVC — это просто обеспечение наличия моделей, представлений и контроллеров в проекте. Нужно поместить HTML-код в представления, код получения из БД в модели и использовать контроллеры для связи всего этого».
Почему это неправильно
- Чрезмерное упрощение ролей: этот ответ упрощает роли моделей, представлений и контроллеров, не понимая их конкретных обязанностей.
- Отсутствие разделения ответственности: ответ недостаточно рассматривает разделение ответственности, которое является ключевым преимуществом использования MVC. Просто связывая компоненты, разработчик упускает суть MVC, которая заключается в максимально возможной децентрализации этих компонентов для обеспечения независимой разработки, тестирования и сопровождения.
- Непонимание лучших практик в архитектуре MVC, таких как размещение бизнес-логики вне контроллеров и представлений.
Эта ошибка часто возникает из-за поверхностного понимания паттерна MVC, возможно, из-за ограниченного опыта работы над проектами, где MVC использовался эффективно, или из-за сосредоточенности на простом запуске приложения без понимания основных принципов проектирования MVC.
Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md