Asp.net mvc без рамки сущности

Я изучаю asp.net mvc и прошел через отличный учебник, который продемонстрировал это. В учебнике также использовалась платформа Entity Framework.

У нас есть собственный класс доступа к данным, который я должен использовать. Я немного смущен относительно того, что мне нужно сделать, чтобы преодолеть разрыв между нашим классом и MVC. Например, в учебнике внутри файла MovieController.cs существует метод Edit, который выглядит следующим образом:

[HttpPost]
        public ActionResult Edit(Movie movie)
        {
            if (ModelState.IsValid)
            {
                db.Entry(movie).State = EntityState.Modified;
                db.SaveChanges();
                return RedirectToAction("Index");
            }
            return View(movie);
        }

Если я не использую инфраструктуру Entity, как бы она выглядела? Должен ли я по-прежнему использовать ModelState.IsValid и сохранить состояние, как это сделано.

db.Entry(movie).State = EntityState.Modified;

Просьба сообщить. Четко написанный пример использования asp.net mvc без использования инфраструктуры Entity был бы замечательным.

Что мне нужно знать, так это то, какую роль играет государство здесь, и обязательно ли это использовать, или это просто часть того, как работает инфраструктура Entity.

Я бы переписал это как:

[HttpPost]
public ActionResult Edit(Movie movie)
{
    myDBObject.SaveChanges();
    return RedirectToAction("Index");

}

Где myDBObject - мой пользовательский объект доступа к базе данных.

Ответ 1

Примеры, которые вы видите там, где контроллеры используют напрямую некоторые структуры доступа к данным, такие как Entity Framework, являются плохими примерами. Весь интернет загрязнен такими вещами. Я едва могу смотреть на него, не ранив глаз. Я считаю их плохими. Доступ к данным должен быть разделен и абстрагирован в репозитории. Так, например:

public interface IMoviesRepository
{
    Movie Get(int id);
    void Save(Movie movie);
}

то у вас может быть некоторая реализация этого интерфейса, используя простые ADO.NET, EF, NHibernate, удаленный вызов веб-службы, некоторые пользовательские ORM или действительно что угодно:

public class MyCustomFrameworkMoviesRepository: IMoviesRepository
{
    ...
}

и контроллер примет этот интерфейс репозитория как аргумент конструктора:

public class MoviesController: Controller
{
    private readonly IMoviesRepository _repository;
    public MoviesController(IMoviesRepository repository)
    {
        _repository = repository;
    }

    public ActionResult Index(int id)
    {
        var movie = _repository.Get(id);
        return View(movie);
    }

    [HttpPost]
    public ActionResult Index(Movie movie)
    {
        if (!ModelState.IsValid)
        {
            return View(movie);
        }

        _repository.Save(movie);
        return RedirectToAction("Success");
    }
}

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

И чтобы ответить на ваш вопрос о собственности государства: это нечто совершенно специфичное для EF, видя что-то подобное в контроллере, очень жаль.

И чтобы довести это еще дольше и улучшить его, вы бы представили модели взглядов. Модели просмотра - это классы, которые специально разработаны для удовлетворения требований данного вида. Так, например, Movie - это модель домена. Доменные модели никогда не должны напрямую передаваться в представления. Действия контроллера не должны воспринимать модели домена как аргументы действия. Вы должны определить модели просмотра, которые будут содержать только то, что требуется данному представлению, а затем выполнить сопоставление между моделями представлений и моделями доменов. Рамки, такие как AutoMapper, делают это очень просто.

Ответ 2

гм.

MVC и структура сущности действительно не имеют ничего общего друг с другом; они просто хорошо работают вместе.

if (ModelState.IsValid) проверяет вашу модель просмотра. Если вы не используете объекты просмотра с помощью валидаторов, это немного бессмысленно; если да, то это весьма ценно.

внутри скобок if (ModelState.IsValid), вы должны взять данные сообщения с вашей веб-страницы (обычно это модель представления) и применить ее к объекту, который будет сохраняться в базе данных. EF часто используется, поскольку после его настройки он довольно прост в обслуживании и намного меньше кода для записи.

            db.Entry(movie).State = EntityState.Modified;
            db.SaveChanges();

связаны как с EF. Они должны быть заменены вашими методами и объектами класса репозитория.

            return RedirectToAction("Index");

- MVC. После успешного сохранения хранилища данных верните элемент управления на индексную страницу.

        return View(movie);

используется для перенаправления на исходное представление, потому что что-то не удалось проверить.

Ответ 3

Вы по-прежнему будете проверять ModelState.IsValid, но в противном случае ваш код будет выглядеть так, как вы.

Это предполагает, что у вашей модели есть атрибуты DataAnnotations, но это то, что используется ModelState.IsValid для проверки. Эти атрибуты могут использоваться для любых свойств класса С#, а не только для платформы Entity Framework.

Вы можете создать определенные модели просмотра для этой цели.

Ответ 4

Вам нужно установить связь между объектом Movie (переданным в http POST) и вашими методами базы данных (myDBObject).

Возможно, вы хотите сказать myDBObject.SaveChanges(movie) и предполагая, что ваш код db знает, как обращаться с объектом Movie, тогда все будет в порядке.