在MVC(CRUD)中创建模型的最佳实践

本文关键字:模型 最佳 创建 MVC CRUD | 更新日期: 2023-09-27 18:21:36

因此,我们为团队添加了一名新的程序员,他对如何在MVC中创建模型有一些想法,这与我们以前创建模型的方式不同。例如,我们有一个系统,用户在其中提交文档请求,并且在该系统中有一个页面,用户在该页面中计算满足文档请求的费用。此费用创建页面可以键入有关费用以及相关发票的一些数据。用户可以添加发票行项目,并使用这些项目自动计算费用总额。在这种情况下,我们通常会创建如下模型。

    public class Fee
{
    public virtual Guid RequestID { get; set; }
    public virtual Guid FeeID { get; set; }
    public string FeeTitle { get; set; }
    public decimal FeeAmount { get; set; }
    public DateTime? DueDate { get; set; }
    public decimal AmountPaid { get; set; }
    public Invoice Invoice { get; set; }
    public List<InvoiceLineItem> LineItems { get; set; }
}
public class Invoice
{ 
    // Additional Invoice Data (To, From, etc)
}
public class InvoiceLineItem
{
    public string LineItemTitle { get; set; }
    public int Quantity { get; set; }
    public decimal PricePerUnit { get; set; }
    public decimal Subtotal { get; set; }
}

我们的新程序员认为这不是一个好方法,因为不同的操作需要不同的数据。例如,当您创建费用时,您需要知道相应的请求ID。但是,当您更新费用时,只需要知道FeeID。因此,当他创建模型时,他以这样一种方式创建模型,即存在多个继承层,以控制在服务层中更新并在视图中显示的数据。他的想法是,我们应该能够假设为事务传递的任何模型都应该使用其所有数据点,而不必根据情况猜测数据是什么。

对我来说,这给我们的模型增加了大量不必要的复杂性,并使在其他模块上使用它们变得更加困难。下面的示例说明了这一点。

 /// <summary>
/// This model is used to present data in a read fashion to the end user
/// </summary>
public class FeeViewModel : FeeModel_Create
{
    public string FullRequestNumber { get; set; }
    public decimal Balance { get; set; }
    public List<String> States { get; set; }
    public List<FeeAttachmentEditModel> Attachments { get; set; }
    public List<PaymentViewModel> Payments { get; set; }
}
/// <summary>
/// This model adds a request id to the fee update model because we need to know which request this fee is associated with
/// </summary>
public class FeeModel_Create : FeeModel_Update
{
    public Guid RequestID { get; set; }
}
/// <summary>
/// Represents the parameters required to update a fee
/// </summary>
public class FeeModel_Update
{
    public virtual Guid FeeID { get; set; }
    public decimal FeeAmount { get; set; }
    public DateTime? DueDate { get; set; }
    public string FeeTitle { get; set; }
    public decimal AmountPaid { get; set; }
    public List<MaterialList> MaterialTypes { get; set; }
    public List<InvoiceLineItem_Adhoc> LineItems { get; set; }
    public Invoice Invoice { get; set; }

    public void InjectValuesIntoInvoiceModel(Invoice Invoice)
    {
        Invoice.Description = this.Invoice.Description;
        Invoice.Terms = this.Invoice.Terms;
        Invoice.To_Name = this.Invoice.To_Name;
        Invoice.To_Address = this.Invoice.To_Address;
        Invoice.To_Address2 = this.Invoice.To_Address2;
        Invoice.To_City = this.Invoice.To_City;
        Invoice.To_State = this.Invoice.To_State;
        Invoice.To_Zip = this.Invoice.To_Zip;
        Invoice.From_Name = this.Invoice.From_Name;
        Invoice.From_Address = this.Invoice.From_Address;
        Invoice.From_Address2 = this.Invoice.From_Address2;
        Invoice.From_City = this.Invoice.From_City;
        Invoice.From_State = this.Invoice.From_State;
        Invoice.From_Zip = this.Invoice.From_Zip;
    }
}

public class InvoiceLineItem_Adhoc
{
    public string Type { get; set; }
    public string EnteredBy { get; set; }
    public decimal Quantity { get; set; }
    public decimal UnitCost { get; set; }
    public InvoiceLineItem ToLineItem(Guid InvoiceID)
    {
        var lineItem = new InvoiceLineItem();
        StaticValueInjecter.InjectFrom(lineItem, this);
        lineItem.InvoiceLineItemID = Guid.NewGuid();
        lineItem.InvoiceID = InvoiceID;
        lineItem.UserID = 1;
        return lineItem;
    }
}
public class PaymentViewModel
{
    public Guid RequestID { get; set; }
    public Guid FeeID { get; set; }
    public string FullRequestNumber { get; set; }
    public string FeeTitle { get; set; }
    public virtual Guid PaymentID { get; set; }
    public decimal PaymentAmount { get; set; }
    public Nullable<System.DateTime> DatePaid { get; set; }
}
public class FeeAttachmentEditModel
{
    public Guid RequestID { get; set; }
    public Guid FeeID { get; set; }
    public string FullRequestNumber { get; set; }
    public string FeeTitle { get; set; }
    public virtual System.Guid FeeAttachmentID { get; set; }
    public System.Guid AttachmentTypeID { get; set; }
    public string AttachmentName { get; set; }
    public byte[] Data { get; set; }
    public string Extension { get; set; }
    public string mimeType { get; set; }
    public string AttachmentBody { get; set; }
    public HttpPostedFileBase FileUpload { get; set; }
    public string FileName { get; set; }
    public bool HadError = false;
}

我只是想在这里找到一个关于MVC中创建模型的最佳实践的答案。是否应该通过继承分部类或其他方式创建单独的模型,以适应正在进行的创建、读取、更新或删除操作。还是最好有一个视图模型来转换视图上显示/传递的内容,以及在访问数据时过滤掉视图模型中重要内容的逻辑?

在MVC(CRUD)中创建模型的最佳实践

我们采用的典型方法是拥有一个与视图紧密耦合的ViewModel,并且只包含该信息。InputModels也是如此,它们应该只包含将要传入的属性。至于继承部分,我将远离这种方法。只需创建简单、平面的DTO,并从您的域模型中映射它们。应该没有逻辑,所以DRY并不真正适用于你的应用程序的这一层。

根据第一个答案,我们还没有看到视图模型将如何在页面上使用。正如他所说,视图模型应该只包含满足显示视图的数据。您不应该只是盲目地将域模型中的每个字段复制到视图模型中。

我也不喜欢视图模型中有HasError标志。使用数据注释或从IValidateableObject继承来对POST执行验证。

我也不认为你需要像在视图模型中那样注入价值观。如果您应该能够从linq查询或webservice请求直接投影到您的视图模型中。

最后一点是,对于页面上的下拉列表,只返回字典或某个小类中所需的数据(Id和描述),这样就不会返回所有数据。

这里有点不清楚你在处理什么。"模型"是一个负担过重的术语,对各种各样的人来说都意味着各种各样的东西。

如果类FeeInvoice等是实体,也就是说它们直接与数据库表相关,那么为了视图的目的对它们进行子类化(就像开发人员所做的那样)是100%错误的。然而,如果它们也只是视图模型,那么子类化它们可能有好处,也可能没有好处。

如果它们是实体,那么您的开发人员是正确的,因为您不应该将整个实体传递到视图或从视图传递。但是,解决方案是创建视图模型,在这种情况下,只包含视图所需的属性。然后将实体中的数据映射到这些视图模型/从这些视图模型映射数据。

关于使用AutoMapper进行映射的要点:您真的不应该使用AutoMaper将映射到实体。图书馆的开发人员自己也说过同样的话。AutoMapper从来没有打算用来将数据映射回实体,如果你这样做,你会遇到实体框架的各种特殊问题。这些都可以解决(我个人在知道之前已经做过很多次了),但是,您开始需要的代码量和必须执行的自定义操作开始否定使用AutoMapper的所有好处。我建议您只需手动将视图模型中的数据映射回实体即可。

您的新开发人员的风格是由技术(在本例中为实体框架)决定的,而在MHO中,这并不总是有利于正确的设计。

我的方法是。。。

模型应该用接口进行逻辑设计——与接口的使用方式无关但将满足未来的需求。遗产应该尽可能地保持浅,而不会破坏一个好的模型设计。

视图只能通过控制器与BS交互。数据服务应仅与业务服务交互。每个演示文稿都应该有自己的ViewModel,它应该尽可能扁平。但是,ViewModel可能具有子ViewModels。

我在数据库服务层中使用DAPPER,并创建了一个代码生成器生成DS方法和存储的proc。DS方法只有相关的属性,以便在数据库中插入/更新字段。这使您的代码精简、快速且易于管理当你离开球队,必须由其他人接手时。