Где мне разместить этот код в MVC?

Question

Мой код работает отлично, НО.Какова лучшая практика в этом случае?

Вот код, который важен.

Это в контроллере.

    private IProductRepository repository;
    [HttpPost]
    public ActionResult Delete(int productId) {
        Product prod = repository.Products.FirstOrDefault(p => p.ProductID == productId);
        if (prod != null) {
            repository.DeleteProduct(prod);
            TempData["message"] = string.Format("{0} was deleted", prod.Name);
        }
        return RedirectToAction("Index");
    }

Это хранилище (оба интерфейсаи т.д.)

public interface IProductRepository {
    IQueryable<Product> Products { get; }
    void SaveProduct(Product product);
    void DeleteProduct(Product product);
}

А вот и хранилище ..... (важная часть) Я хочу отметить, что ... это не фальшивый класс, как это довольно ясно.Тестирование выполняется на поддельных классах.

    private EFDbContext context = new EFDbContext();

    public IQueryable<Product> Products {
        get { return context.Products; }
    }

    public void DeleteProduct(Product product) {
        context.Products.Remove(product);
        context.SaveChanges();
    }

Ну, первый вопрос: при тестировании этого я сделаю два метода TestMethods на контроллере в «ControllerTest».«Can_delete_valid_product» и «Cannot_delete_invalid_product».Есть ли смысл иметь тестовый класс для репозитория?Как и «RepositoryTest», после того, как контроллер проверяет, работает ли функция удаления, нет необходимости проверять его дважды, верно?

Второй вопрос: в этом тесте в контроллере, если продукт существует, перед попыткой его удаления.Если он существует, я вызываю функцию удаления в хранилище.Это означает, что не должно быть возможности исключения.НО вы все равно можете создать исключение в хранилище, если отправите ноль.(что не может произойти здесь, но вы все равно можете сделать это, если вы забудете проверить, если ноль).Вопрос в том, стоит ли вместо этого проводить проверку наличия продукта в хранилище?

Answer 1

Я предпочитаю держать логику вне контроллера по большей части.Тест действия контроллера проверяет, вызывается ли хранилище, но само хранилище проверяется в этом тесте.Я бы сделал хранилище ответственным за обработку нулевой проверки.

Answer 2

1. Лично я создаю отдельные тесты для своих репозиториев / доступа к данным, чтобы убедиться, что они работают правильно. Сами контроллеры будут проверяться с помощью макетов.

2. На самом деле вполне возможно (возможно, не очень вероятно), что кто-то может удалить продукт так же, как кто-то другой пытается его удалить. В этом случае вы, вероятно, не заботитесь / не должны знать, что кто-то сделал это, поэтому я, вероятно, просто проглотил бы это исключение в репозитории (хотя я сначала запишу его). С точки зрения нулевой проверки / защитного программирования это полностью личный выбор. Некоторые люди оставляют подобные проверки в точках входа в систему, где другие создают многоуровневую защиту, которая имеет дополнительные проверки по всему коду. Проблема в том, что эти проверки могут быть довольно уродливыми, что является большой причиной того, почему я желаю, чтобы Кодовые контракты получили бы больше тяги.

Answer 3

Это означает, что не должно быть возможности исключения.НО вы все равно можете создать исключение в хранилище, если отправите ноль.(что не может произойти здесь, но вы все равно могли бы сделать это, если забыли проверить, имеет ли значение null).

Или если оно удалено после того, как вы проверите его, но перед его удалением.Или если вы потеряете соединение с хранилищем (или метод никогда не вернется в этом случае?).Вы не можете избежать исключений таким образом.