Asp.Net 程序架构答案

【问题标题】：Asp.Net Program ArchitectureAsp.Net 程序架构
【发布时间】：2011-02-24 09:15:35
【问题描述】：

我刚刚使用了一个新的 Asp.Net MVC 应用程序，打开它后发现以下内容，

[项目].Web
[项目].Models
[项目].BLL
[项目].DAL

现在，很清楚的一点是，数据在进入视图之前必须做很多工作（Database>DAL>Repo>BLL>ConvertToModel>Controller>View）。 DAL 是亚音速的，DAL 中的存储库将亚音速实体返回给 BLL，BLL 处理它们会做一些疯狂的事情并将它们转换为模型（来自 .Models），有时类看起来像这样

public DataModel GetDataModel(EntityObject Src)
{
    var ReturnData = new DataModel():
    ReturnData.ID = Src.ID;
    ReturnDate.Name = Src.Name;

    //etc etc
}

现在的问题是，“这完全是矫枉过正吗”？好的，这个项目规模不错，只能变得更大，但值得继续进行这一切吗？我不想使用 AutoMapper，因为它似乎使并发症变得更糟。任何人都可以对此有所了解吗？

【问题讨论】：

标签： asp.net asp.net-mvc architecture

【解决方案1】：

现在的问题是，“这完全是矫枉过正吗”？

是的，这太过分了。有人正在尝试构建一个 3-Tier/n-Tier 和 MVC 的应用程序，但没有意识到根据您的观点，MVC 本身就是构建 n-Tier 应用程序的一种方式，每个主要/传统层已经是 MVC 首字母缩略词的一部分，或是您使用的替代架构，而不是 n-Tier。无论哪种方式，将 DAL/BLL 类与 MVC 一起查看只是有点奇怪。

要记住的另一件事是，您可能只有一个 Web 应用程序。有时，有一个 winforms“智能客户端”或其他应用程序与同一个数据库对话，并且实际上是同一个系统的一部分——例如，面向消费者的电子商务站点视图和同一个库存数据库的销售代表视图。在这种情况下，传统的 DAL 和 BLL 可能是个好主意，因为它们可以在系统中的每个不同应用程序之间共享。但是，如果您这样做，您可能应该查看服务层。

【讨论】：

【解决方案2】：

首先，我认为您不愿意使用 AutoMapper 令人惊讶地不合逻辑。我可以看到不引入另一个第三方库的原因，但在这种情况下，AutoMapper 真的不会使事情复杂化，只要你正确地连接它并在正确的地方（即只有一个地方......）。

其次，整个 ASP.NET MVC 框架的出现是为了让开发人员能够构建松散耦合、可扩展和“可插入”的应用程序。这确实意味着如果你要选择一条路然后沿着那条路走，那么要做更多的工作来做同样的事情，这是正确的。但是一旦你决定改变一些东西——也许你决定从 Subsonic 转移到其他供应商，或者毕竟使用 AutoMapper——你会注意到你只需要重写应用程序的相关部分，而不是整个事情。
（我并不是说如果您切换数据库引擎，您必须从头开始重写 WebForms 应用程序，但如果您没有努力工作，您将不得不查看几乎所有应用程序代码来更新代码的相关部分解耦就足够了。在这种情况下，您不会通过选择 WebForms 而不是 MVC 来节省任何工作......）

简而言之：是的，这对您来说意味着更多的工作，而不仅仅是“一起破解”。它看起来确实比看起来必要的复杂。但是，一旦您开始对某事改变主意（而且您会的），您就会称赞您的幸运星从一开始就以“正确的方式”*做到了。

*) 没有这样的东西。我知道。

【讨论】：