ASP.NET程序体系结构

弗斯特 我认为你不愿意使用automapper是非常不合逻辑的。我可以看到不带另一个第三方库的原因,但在这种情况下,automapper确实不会使事情复杂化,只要你把它正确地连接在正确的地方(即只有一个地方…)。

其次 整个ASP.NET MVC框架的出现是为了让开发人员能够构建松散耦合、可扩展和“可插入”的应用程序。如果你要选择一条路,然后沿着这条路走,这就意味着要做更多的工作。但是一旦你做出改变的决定——也许你决定从亚音速转向其他供应商,或者最终使用automaper——你会发现你只需要重新编写应用程序的相关部分,而不是整个程序。
(我并不是说,如果您切换数据库引擎,就必须从头重写WebForms应用程序,但是如果您在去耦方面没有足够的努力,那么您将不得不浏览几乎所有的应用程序代码来更新代码的相关部分。在这种情况下,您不会通过选择WebForms而不是MVC来保存任何工作…)

简而言之: 是的,这意味着对你来说不仅仅是“一起黑客”。它看起来确实比看起来更复杂。但是一旦你开始改变主意(并且你会改变主意),你就会称赞你的幸运星从一开始就“正确”地做到了。

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

现在,问题是,“这是完全的过度杀戮吗?”

是的,太过分了。有人正在尝试构建一个3层/n层的应用程序 和 MVC没有意识到,根据您的观点,MVC本身就是一种可以构建N层应用程序的方式,其中每个主/传统层都已经是MVC首字母缩写的一部分, 或 您使用的替代体系结构,而不是n层。不管怎样,看到DAL/BLL类和MVC只是有点奇怪。

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