C# 这是MVC反模式吗？

我对任何类型的.NET web开发都是非常陌生的（到目前为止，我主要使用Winforms和services）。我已经开始与其他两位开发人员一起处理现有的MVC3项目。我在概念上熟悉MVC，并且正在努力了解它在这个项目中的使用情况

我们有一个AccountDto类来表示帐户。每个实体都有一个由另一个类继承的响应类，即AccountResponse：

public class Response
{
    [DataMember]
    public bool IsSuccess{get;set;}

    [DataMember]
    public string DisplayMessage { get; set; }

    [DataMember]
    public string DetailedMessage { get; set; }

    [DataMember]
    public ErrorType ErrorType { get; set; }

    public Response(){
        this.IsSuccess=true;
        this.ErrorType = ErrorType.None;
    }
}

public partial class AccountResponse : Response
{
    [DataMember]
    public IList<AccountDto> AccountList { get; set; }
}

这对我来说是有意义的，尽管我不确定成功/错误消息将被用于何处。但是，他们现在希望从在视图中使用DTO切换到使用响应，因此必须在视图中处理成功/失败：

public ActionResult ToBeCalled(int id)
{
    var response = _accountService.GetAccountByAccountId(Convert.ToInt64(id));
    return View(response);
}

对我来说，这似乎是错误的——我没有按照DTO作为模型进行编码，而是必须为每个页面执行以下操作：

@{
    if (Model.IsSuccess)
    {
        var account = Model.AccountList.FirstOrDefault();

        if (account != null)
        {
            @Html.HiddenFor(x => account.AccountNumber)
        }
}

控制器的ActionResult/HttpPost方法还必须解析来自这些响应对象的DTO。对我来说，这似乎是一种反模式；这样的做法正常吗

---

抱歉，如果这太长，请迁移，如果它属于代码审查或其他网站。

我同意你的看法，这将是一种反模式。这种观点被认为是相当无知的，尤其是对于这样的逻辑

如果成功和失败之间的差异只是UI的一小部分，我可以理解为什么这会很诱人，但是想象一下如果这种情况改变了。视图几乎没有能力（没有不必要的部分嵌套）切换到完全不同的视图。它无法发出重定向或其他错误代码。如果您决定更改UI，则可能需要返回并再次重写控制器

---

如果将逻辑移动到视图背后的原因是从控制器中删除

response.issucess

逻辑（老实说，这对我来说似乎很好；它与经典的

Model.IsValid

）几乎相同，您可以考虑另一种方法：重构您的<代码>响应< /代码>类以继承<代码> Actudio结果< /代码>。然后，您可以将该逻辑移动到

executesult（）

方法中，它将与控制器分离。

只需使用coalesce操作符，您就可以摆脱大量的错误（比如奇怪的响应基类（如果它继续存在，应该将其标记为abstract））并避免空检查

public ActionResult ToBeCalled(int id)
{
    var response = _accountService.GetAccountByAccountId(id) ??
        new AccountResponse();
    return View(response);
}

更好的是，将该逻辑迁移到您的服务类中，这样它就可以保证对象的返回（对于存储库来说，在没有支持实体的情况下这样做并不一定有意义，但对于服务来说是有意义的）

---

无论哪种方式，您都不需要在视图中包含难看的空检查或if/else逻辑。将尽可能多的逻辑转移到你可以测试的地方，你会更快乐。

我参与的第一个MVC项目，有一个几乎相同的模式（实际上有点吓人），我的想法和你完全一样。FWIW我同意@bhamlin belowit的非常程序化的观点。控制器是这个概念中的关键要素。我们需要的是真实的对象，而不是程序控制器。

@{
    if (Model.IsSuccess)
    {
        var account = Model.AccountList.FirstOrDefault();

        if (account != null)
        {
            @Html.HiddenFor(x => account.AccountNumber)
        }
}

public ActionResult ToBeCalled(int id)
{
    var response = _accountService.GetAccountByAccountId(id) ??
        new AccountResponse();
    return View(response);
}