mvc web应用程序应该是3层吗？

Question

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

在我现有的web应用程序中，在delphi中完成，数据访问层被分离成一个完全独立的应用程序，有时运行在不同的服务器上。对于代码重用而言，这比结构化原因更重要。这不会成为下一个应用程序的一个因素，因为它会全新的。

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

编辑：只是为了澄清;我使用术语层来指代单独的物理应用程序，不仅仅是逻辑分隔或层。

Answer 1

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

MVC - 指3“图层”与担心分离围绕3模型（数据），视图（UI），控制器（应用程序逻辑）的关注。

现在，我已经作出关于我术语的区别..

是具有在MVC应用程序独立的数据访问应用程序矫枉过正？

我想说没有（同样取决于你的应用程序的意思），它不是矫枉过正，因为它可能在事实上导致更易于维护的系统。您的ORM将可能允许插入新的数据访问选项，但如果您希望添加新的ORM，该怎么办？拥有清晰分离的数据访问层（DAL）将为您的应用程序的这方面提供更大的未来灵活性。另一方面，根据应用程序的规模和愿景，创建一个完全独立的数据访问选项可能是矫枉过正的，但简而言之，将DAL分离为不同的组件是非常推荐的做法实现MVC模式的应用程序的一部分。

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

Answer 2

非常棒的评论Tobias。

我说要添加足够的图层，以便它对您有意义并使其更易于维护。也要保持关注的分离。

Answer 3

嗯，我客串这取决于你是否在谈论层（身体属性）或层（逻辑/项目）一点点。

关于分层 - 你可以看看像s＃arp architecture（code.google.com/p/sharp-architecture/）这样的例子，他们是如何做到这一点的（他们采取了一种非常极端的分层方法）。

对于这里更简约的观点为例，看看Ayende的博客：ayende.com/Blog/

关于层 - 我觉得不必要添加额外的层次，并把寄托都通过电线将正好碰到你的表现，除非你出于容量原因需要这样做。正确地获取图层，并且当你需要调整容量时，它们将它们分开放置（如果你已经很好地分离了你的关注点，不应该花费太多的重构）。