将ASP.NET MVC转换为n层架构

3
我刚刚使用了ASP.NET MVC构建了一个应用程序。我们公司的程序员希望以后所有的模块都使用n层架构(表现层、业务逻辑层、数据访问层)。我不是程序员,需要知道为什么这样做有意义?我是否必须完全重写整个代码或可以进行转换?
我们正在构建一个包含商业智能的HRIS系统。
请有人解释一下,为什么这种方法是明智的或不明智的。
4个回答

3
说实话,我不太明白。
在“N层”架构中,您有三层:
- 数据访问层 - 业务逻辑层 - 表示层
在MVC(Model、View、Controller的缩写)中,您有三个层次:
- 模型(数据访问层)(如果使用存储库模式) - 视图(表示层) - 控制器(业务逻辑层)
简而言之,您的应用程序已经编写完成,并提供了关注点分离。现在他们想要重写它,实质上只是重新命名文件夹?
这根本没有任何意义。

3
仅仅因为他们使用了MVC并不意味着他们拥有“N层”架构。“N层”(应该)用于破除层之间的依赖关系。仅仅使用MVC并不能强制执行这一点。例如,将数据访问模型传递给视图是完全可能的,从而使表示层依赖于数据访问层。对于这种类型的依赖性,您将不再具有具有单独层的好处。 - Matt Lacey
1
仅仅因为某件事情“可能”发生,并不意味着它在他的特定情况下会发生。在N层应用程序中,数据访问层可以有业务逻辑,这是完全可能的,但这并不意味着它应该发生。当涉及到关注点分离时,良好构建的MVC应用程序与良好构建的N层应用程序相同。 - George Stocker

1

在不了解您的问题细节的情况下,有一些问题可以讨论:

三层架构是一个好主意,因为它们往往可以将其组成部分的类的问题轻松地分离到更灵活易懂的类别中:

1)数据/持久性 2)业务逻辑 3)表示/GUI

遵循这种基本模式确实在涉及数据收集和检索(大多数商业应用程序)的任何软件项目中都很有意义。还有其他几十个原因,这里无法一一列举。

现在,通过重构现有代码库来达到三层架构取决于该代码如何开发。这引出了古老的软件开发问题:我们重构还是从头开始?一切都取决于代码……以及编写“新”代码的人。

我建议,如果您的程序员对领域和他们试图实现的内容有很好的了解(或者有卓越的技术规范),即使重构似乎是可能的,重写也可能有用。相反,如果这些程序员对问题领域没有专业知识或者没有规范,则尝试将现有逻辑重构为三个层,并因此保存最初建立的业务逻辑可能会很有价值。

简而言之,已经有很多书籍探讨了你面临的困境。但这里我提到的两个编程经验法则会出现在任何软件开发手册中:
  • 良好的结构例如三层架构、MVC、模式等
  • 重构是好的-可以产生更清晰、更易于维护、更具性能和可读性的代码
祝你好运!

1

层次结构更多地与物理架构有关,而不是逻辑架构?请参见多层架构

如果您在当前应用程序中已将M、V和C分开,则已经具有良好的逻辑架构。

如果开发人员认为某些问题没有得到适当的分离,我会要求他们将现有代码重构为更小的块(具有单一职责的较短方法和类),并将这些块移动到相关的层/程序集/命名空间中,例如,如果您的MVC应用程序确实具有持久性,而这不是MVC的要求,则将数据访问代码移动到数据访问层中。


0

三层架构确实可以促进后续更好的可重用性。事实上,您最近构建的基于MVC的应用程序可以利用三层模型(至少是模型和控制器部分)。MVC控制器可以充当外观,利用后台的三层解决方案。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接