2010-01-05 118 views
3

我刚刚使用ASP.NET MVC构建了一个应用程序。我公司的程序员希望使用n-Tiered(表示层,业务逻辑层,数据访问层)架构构建所有未来的模块。将ASP.NET MVC转换为n层结构

我不是程序员,需要知道为什么这有意义吗?我必须完全重写整个代码还是可以将其转换?

我们正在构建商业智能HRIS系统。

有人请解释为什么或为什么不这样做或没有意义。

回答

1

不知道你的问题更多的细节有可以讨论的几个问题:

三层架构是一个好主意,因为他们往往很容易区分,使它们成更灵活的类的担忧和易于理解的类:

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

在此之后的基本模式有一定道理对于任何软件项目中的数据收集和检索(绝大多数biz应用程序)涉及。还有其他许多原因,并且在这里列出的数量太多。

现在,能够通过重构现有代码库来实现三层体系结构,很大程度上取决于代码的开发方式。这引发了一个古老的软件开发问题:我们重构还是从头开始?这一切都取决于代码......以及编写“新”代码的人员。

我会建议,如果你的程序员对领域和他们正在努力完成的事情(或恒星技术规范)有很好的了解,那么重写可能是有用的,即使重构似乎是一种可能性。相反,如果那些相同的程序员在问题领域没有专业知识或者没有规范,那么尝试将现有逻辑重构为三层并因此保留最初建立的商业逻辑是值得的。

总之,很多书都写在你面临的困境上。但是我在这里覆盖了两个编程规则,它将在任何软件开发手册中出现:

  • 结构很好,例如,三层架构 ,MVC,图案
  • 重构是很好的 - 导致 更清洁,更容易维护, 高性能,易于理解的代码

祝你好运!

0

3层方法的确可以提高路上的可重用性。实际上,您最近构建的基于MVC的应用程序可以利用3层模型(至少是模型和控制器部分)。 MVC控制器可以充当背景中使用3层解决方案的外观。

3

老实说,这对我没有意义。

在 “N层” 的架构,你有三个层次:

  • 数据访问层
  • 业务逻辑层
  • 表示层

在MVC(以下简称中号 odel,V查看,C ontroller),你有三层:

  • 模型(数据访问层)(如果你使用Repository模式)
  • 视图(表示层)
  • 控制器(业务逻辑层)

总之,你的应用程序已经书面,提供了关注的分离。现在他们想重写它基本上只是重命名文件夹?

这根本没有意义。

+3

仅仅因为他们使用MVC并不意味着他们有“N层”架构。 “N层”(应该)用于打破层之间的依赖关系。简单地使用MVC不会强制执行此操作。例如,完全有可能将数据访问模型传递给视图,从而使表示层依赖于数据访问层。有了这种依赖关系,您就不再拥有分层的好处。 – 2010-01-05 13:57:08

+1

仅仅因为这是'可能'并不意味着它发生在他的特殊情况下。数据访问层中的业务逻辑完全可能用于N层应用程序,但这并不意味着它应该发生。一个构建良好的MVC应用程序与构建良好的N层应用程序的问题相同。 – 2010-01-05 14:05:45

1

层与物理体系结构的关系比逻辑层更多。请参阅Multi-tier architecture

如果您在当前应用程序中彼此分离了M,V和C,则您已经拥有良好的逻辑体系结构。

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