我刚刚使用ASP.NET MVC构建了一个应用程序。我公司的程序员希望使用n-Tiered（表示层，业务逻辑层，数据访问层）架构构建所有未来的模块。
我不是程序员，需要知道为什么这有意义？我是否必须完全重写整个代码或者是否可以转换它？
我们正在建立一个商业智能的HRIS系统。
有人请解释为什么或为什么这种方法没有意义。
答案 0 :(得分：3)
老实说，这对我没有意义。
在“N-Tier”架构中，您有三个层次：
在MVC（ M odel， V iew， C ontroller）的简称中，您有三个层次：
简而言之，您的应用程序已经编写，和提供了关注点分离。现在他们想重写它基本上只是重命名文件夹？
这根本没有意义。
答案 1 :(得分：1)
如果不了解有关您问题的更多详细信息，可以讨论一些问题：
三层体系结构是个好主意，因为它们可以轻松地将类的关注点分开，使它们变得更加灵活和易于理解：
1）数据/持久性2）业务逻辑3）表示/ GUI
对于涉及数据收集和检索（绝大多数商业应用程序）的任何软件项目，遵循此基本模式确实有意义。还有许多其他原因，也有太多，无法在此列出。
现在，能够通过重构现有的代码库来实现三层体系结构，这在很大程度上取决于代码的开发方式。这带来了古老的软件开发问题：我们是重构还是从头开始？这一切都取决于代码......以及编写“新”代码的人。
我建议如果你的程序员对领域和他们想要完成的东西（或一个出色的技术规范）有很好的了解，那么即使重构似乎是一种可能性，重写也是有用的。相反，如果那些相同的程序员在问题领域没有专业知识或者没有规范，那么尝试将现有逻辑重构为三层并从而保留最初建立的业务逻辑也许是值得的。
简而言之，很多书都是关于你所面临的困境的。但是我在这里介绍了两个编程规则，它们将出现在任何软件开发手册中：
答案 2 :(得分：1)
层与物理架构的关系比逻辑层更多？见Multi-tier architecture
如果您在当前应用程序中已经将M，V和C分开，那么您已经拥有了良好的逻辑架构。
如果开发人员认为某些问题没有得到正确分离，我会要求他们将现有代码重构为较小的块（较短的方法和具有单一责任的类），并将它们移动到相关的层/程序集/命名空间中，无论您看到什么如果您的MVC应用程序确实具有不是MVC要求的持久性，则适合（例如）数据访问代码到数据访问层。
答案 3 :(得分：0)
三层方法确实确实可以促进更好的可重用性。事实上，您最近构建的基于MVC的应用程序可以使用3层模型（至少是模型和控制器部分）。 MVC控制器可以充当外观，利用背景中的3层解决方案。