【问题标题】:Mvc core edit action not savingMvc核心编辑动作不保存
【发布时间】:2018-10-16 20:54:36
【问题描述】:

所以,我有这个用户实体

using System;
using System.Collections.Generic;
using System.Text;
using Transport.Data.Entities;

namespace Transport.Data.Entities
{
    public class User : BaseEntity
    {
        public String FirstName { get; set; }
        public String LastName { get; set; }
        public DateTime BirthDay { get; set; }
        public String Email { get; set; }
        public String UserName { get; set; }
        public bool IsActive { get; set; }
        public List<Viaje> Viaje { get; set; }    
    }
}

这里是实体的 ViewModel

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations.Schema;
using System.Text;
using Transport.Data.Entities;
using Transport.Model.Infraestructure;

namespace Transport.Model.ViewModel
{
    public class ViajeViewModel : BaseViewModel
    {
        public string Route { get; set; }
        public string Destination { get; set; }
        public string Origin { get; set; }
        public int Price { get; set; }
        public DateTime DepartureTime { get; set; }
        public int UserId { get; set; }
        [ForeignKey("UserId")]
        public Viaje Viaje { get; set; }
        public List<User> User { get; set; }
    }
}

这是我的更新存储库

DataResult IRepository<T>.Update(T entity)
{
    DataResult result = new DataResult();

    try
    { 
        result.Data = entity;
        context.SaveChanges();
        result.Successfull = true;
    }
    catch (Exception ex)
    {
        result.LogError(ex);
        result.Successfull = false;
    }

    return result;
}

还有我的更新服务

public ServiceResult Update(Vm viewModel)
{
    ServiceResult serviceResult = new ServiceResult();

    var ToUpdate = this.Repository.GetById((int)viewModel.Id).Data;

    if (ToUpdate == null)
    {
        serviceResult.Success = false;
        serviceResult.ResultTitle = "ERROR: Record No Found";
        //serviceResult.Messages.Add(Error.GetErrorMessage(Error.RecordNotFound));

        return serviceResult;
    }

    var Entity = MapperHelper.Instance.Map<Vm, Ent>(viewModel);

    var result = this.Repository.Update(Entity);

    serviceResult.Success = result.Successfull;
    serviceResult.ResultTitle = (result.Successfull ? Error.GetErrorMessage(Error.CorrectTransaction) : Error.GetErrorMessage(Error.InternalServerError));
    //serviceResult.Messages.Add(result.Successfull ? "Updated" : "Failed");
    serviceResult.ResultObject = MapperHelper.
    Instance.Map<Ent, Vm>(result.Data);

    this.Repository.SaveChanges();
    return serviceResult;
}

这是我的更新用户控制器

[HttpPost("users/edit/{id}")]
public ActionResult UserEdit(UserViewModel userViewModel)
{
    var users = userService.Update(userViewModel).ResultObject;

    return RedirectToAction("Index", "Users");
}

存储库和服务正在通过 id 查找用户并更新其值,但是当 UserEdit 控制器完成时,我的更改没有保存在数据库中。

谁能给我一些建议来解决这个问题?

【问题讨论】:

  • 为什么标题是洋葱架构,而这是简单的 CRUD?
  • @AdamWyżgoł 只是想更具体一些
  • 跟踪的实体是 ToUpdate 但您正在尝试更新映射的视图模型对象。使用视图模型中的属性更新 ToUpdate 的属性。

标签: c# asp.net-core asp.net-core-mvc


【解决方案1】:

EF 依靠内部实体更改跟踪来确定它需要在数据库中执行的操作。您的所有Update 方法所做的只是调用SaveChanges,因此由于某种原因不会跟踪对实体所做的更改,并且当您调用SaveChanges 时,EF 看不到它需要做的任何工作,而只是返回。至于为什么没有跟踪您的实体更改,这里没有足够的存储库来说明。

但是,我会说这是将存储库模式与 EF 一起使用的最重要原因之一。做一些破坏 EF 变更跟踪的事情太容易了,而且 100 次中有 99 次,这正是开发人员所做的。当您使用像 EF 这样的 ORM 时,that 就是您的数据层。它已经实现了存储库和工作单元模式。并非架构中的每个“层”都必须由您实际拥有,这是太多开发人员犯的严重错误。只需直接使用您的上下文。这就是它的用途。

现在,纯粹主义者可能会争辩说,您将严重依赖 EF。好吧,你猜怎么着?你不管。您已选择它作为 ORM,而该决定不会也不应该轻易做出。如果你想用其他东西把它换掉怎么办?这个问题也总是被提出来。简单地说,你不会。切换 ORM 之类的东西所涉及的摩擦使得它永远不会成为业务优先事项。

尽管如此,如果您想真正抽象依赖关系,您应该考虑像 CQRS 或微服务这样的模式,它们与冗余和无用的存储库层不同,实际上确实为您的应用程序增加了价值。但是,对于大多数应用程序来说,这些模式实现起来很复杂,而且过于繁琐。

【讨论】:

  • 如果我在这里错了,请纠正我,但是使用存储库模式会在您的控制器和 EF 之间放置一些距离,因此您的整个应用程序不依赖于 EF,只有您的数据层/存储库是。
  • 不正确。存储库模式用于低级数据访问,例如实际的 SQL 查询字符串。在存储库中包装 EF 并不会神奇地使依赖关系消失。您仍在代码中使用 LINQ to Entities 等,如果您使用 DI,并且应该使用,您仍然需要在您的存储库中注入上下文,因此应用程序仍然知道它。无论如何,您的应用中仍然会引用 EF,而且没有办法解决。
  • 换句话说,它并没有实现人们使用它的任何预期目标,而且它也是多余的,只是需要更多的代码来维护和测试。
  • 存储库模式将数据上下文与控制器分离。依赖项永远不会神奇地消失,您只需将它们移动到一个位置,使您能够以尽可能少的麻烦替换它们。直接从控制器使用 EF 意味着如果您决定放弃 EF,则必须重写整个内容。
  • 另一方面,该死的确保您使用正确的工具来预先访问数据,这样您以后就不必删除它们了。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-05-12
  • 1970-01-01
  • 2011-08-11
相关资源
最近更新 更多