asp.net-mvc - MVC Web 应用程序应该是 3 层吗？

Question

我将很快设计几个 Web 应用程序。它们可能会在 asp.net mvc 中完成。

在我现有的使用 delphi 完成的 Web 应用程序中，数据访问层被分离成一个完全独立的应用程序，有时在不同的服务器上运行。这样做更多是为了代码重用，而不是出于架构原因。这不会成为下一个应用程序的一个因素，因为它将是全新的。

在 mvc 应用程序中使用单独的数据访问应用程序是否太过分了？我已经通过使用 MVC 来分离业务类，并且我将使用 ORM 来执行数据库持久化。

编辑:只是为了澄清；我使用术语层来指代分离的物理应用程序，不仅仅是逻辑分离或层。

Answer 1

根据我的经验，术语“ Tier ”通常是指物理应用程序分离，例如客户端层和服务器层。

MVC - 指的是 3 个“ 层 ”，关注点是围绕 3 个关注点进行分离，它详细介绍了模型(数据)、 View (UI)、 Controller (应用程序逻辑)。

现在我已经对我的术语做出了区分。

Is having a separate data access application overkill in a mvc app?

我会说 否 (再次取决于您所说的应用程序的含义)， 这不是矫枉过正 ，因为它实际上可能会导致更易于维护的系统。您的 ORM 可能会允许插入新的数据访问选项，但是如果您希望添加新的 ORM 怎么办？拥有一个明确分离的数据访问层 (DAL) 将允许您在应用程序的这方面具有更大的 future 灵活性。

另一方面，根据应用程序的规模和愿景，创建一个完全独立的数据访问选项可能有点矫枉过正，但简而言之，将 DAL 分离到不同的程序集是在实现MVC 模式。

希望这会有所帮助，如果您需要更深入的评论。