Asp.Net程序架构

Question

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

1. [项目].Web
2. [项目].模型
3. [项目].BLL
4. [项目].DAL

现在，很清楚的是，数据在到达 View 之前必须做很多事情(数据库>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，因为它似乎会使复杂性变得更糟。有人能解释一下吗？

Answer 1

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

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

简而言之:是的，这对您来说意味着更多的工作，而不仅仅是“一起破解某些东西”。它看起来确实比看起来必要的更复杂。但一旦你开始改变对某件事的想法(你会的)，你就会称赞你的幸运星，因为你从一开始就以“正确的方式”*做到了这一点。

*) 没有这样的事情。我知道。