在MVC（CRUD）中创建模型的最佳实践

问题描述 投票：0回答：4

因此，我们为团队添加了新的程序员，他对应该如何在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中创建模型的最佳实践的答案。您是否应该通过继承子类或其他方式来创建单独的模型，以适应要进行的创建，读取，更新或删除操作。还是最好有一个视图模型转换为在视图上显示/传递的视图，以及在访问数据时过滤掉来自视图模型的重要内容的逻辑？

c# asp.net-mvc model-view-controller asp.net-mvc-viewmodel
4个回答
5
投票

我们采用的典型方法是使ViewModel与视图紧密耦合，并且仅包含该信息。 InputModels也是如此，它们应该只包含将要传入的属性。至于继承，我会远离这种方法。只需创建简单，平坦的DTO并从您的域模型中进行映射即可。应该没有逻辑，因此DRY不会真正应用于您的应用程序的这一层。

1
投票

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

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

我也不认为您需要像在视图模型中那样注入值。如果您应该能够从linq查询或网络服务请求直接投射到您的视图模型中。

最后一点是，对于页面上的下拉列表，仅在字典或某个小类中返回所需的数据（Id和描述），因此您不会返回所有数据。

1
投票

有点不清楚您在这里处理什么。 “模型”是一个负载词，对各种各样的人可能意味着各种各样的事情。

[如果类Fee，Invoice等是实体，也就是说它们直接与数据库表相关，则为视图目的将它们子类化，就像您的开发人员所做的那样，为100 ％错误。但是，如果它们也只是视图模型，那么对它们进行子类化就没有好处。

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

关于使用AutoMapper进行映射的要点：您确实不应使用AutoMapper映射to实体。图书馆的开发者自己也这么说。从来没有打算将AutoMapper用于将数据映射回实体，如果这样做，您将遇到Entity Framework的各种特殊问题。所有这些都可以解决（在我更了解之前，我已经做过很多次），但是您开始需要的代码量和必须要做的自定义操作开始抵消了使用AutoMapper的所有好处。地点。我建议您只需手动将视图模型中的数据映射回您的实体。

0
投票

您的新开发人员的风格由该技术（在本例中为实体框架）决定-在MHO中，该技术并不总是适合适当的设计。

我的方法是...

模型应在逻辑上设计为具有接口-不知道如何使用它们但可以满足将来的要求。继承应保持尽可能浅，而不会破坏继承模型设计。

视图仅应通过控制器与BS交互。数据服务应仅与业务服务进行交互。每个演示文稿应具有自己的ViewModel，该ViewModel应该尽可能平坦。但是，ViewModel可能具有子ViewModel。

我在数据库服务层中使用DAPPER，并创建了一个代码生成器，生成DS方法和存储的proc。 DS方法只会包含在数据库中插入/更新字段的属性。这使您的代码更加精简，快速且易于管理当您离开团队时，其他人必须接管。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.