我刚刚使用了ASP.NET MVC构建了一个应用程序。我们公司的程序员希望以后所有的模块都使用n层架构(表现层、业务逻辑层、数据访问层)。我不是程序员,需要知道为什么这样做有意义?我是否必须完全重写整个代码或可以进行转换?
我们正在构建一个包含商业智能的HRIS系统。
请有人解释一下,为什么这种方法是明智的或不明智的。
我们正在构建一个包含商业智能的HRIS系统。
请有人解释一下,为什么这种方法是明智的或不明智的。
在不了解您的问题细节的情况下,有一些问题可以讨论:
三层架构是一个好主意,因为它们往往可以将其组成部分的类的问题轻松地分离到更灵活易懂的类别中:
1)数据/持久性 2)业务逻辑 3)表示/GUI
遵循这种基本模式确实在涉及数据收集和检索(大多数商业应用程序)的任何软件项目中都很有意义。还有其他几十个原因,这里无法一一列举。
现在,通过重构现有代码库来达到三层架构取决于该代码如何开发。这引出了古老的软件开发问题:我们重构还是从头开始?一切都取决于代码……以及编写“新”代码的人。
我建议,如果您的程序员对领域和他们试图实现的内容有很好的了解(或者有卓越的技术规范),即使重构似乎是可能的,重写也可能有用。相反,如果这些程序员对问题领域没有专业知识或者没有规范,则尝试将现有逻辑重构为三个层,并因此保存最初建立的业务逻辑可能会很有价值。
简而言之,已经有很多书籍探讨了你面临的困境。但这里我提到的两个编程经验法则会出现在任何软件开发手册中:层次结构更多地与物理架构有关,而不是逻辑架构?请参见多层架构。
如果您在当前应用程序中已将M、V和C分开,则已经具有良好的逻辑架构。
如果开发人员认为某些问题没有得到适当的分离,我会要求他们将现有代码重构为更小的块(具有单一职责的较短方法和类),并将这些块移动到相关的层/程序集/命名空间中,例如,如果您的MVC应用程序确实具有持久性,而这不是MVC的要求,则将数据访问代码移动到数据访问层中。
三层架构确实可以促进后续更好的可重用性。事实上,您最近构建的基于MVC的应用程序可以利用三层模型(至少是模型和控制器部分)。MVC控制器可以充当外观,利用后台的三层解决方案。