我将很快设计几个 Web 应用程序。它们可能会在 asp.net mvc 中完成。
在我现有的 web 应用程序中，使用 delphi 完成，数据访问层被分离成一个完全独立的应用程序，有时运行在不同的服务器上。这样做更多是为了代码重用，而不是出于架构原因。这不会成为下一个应用程序的一个因素，因为它将是全新的。
在 mvc 应用程序中使用单独的数据访问应用程序是否过大？我已经通过使用 MVC 分离出业务类，并且我将使用 ORM 来执行数据库持久性。
编辑：只是为了澄清；我使用术语层来指代单独的物理应用程序，而不仅仅是逻辑分离或层。
根据我的经验，术语“层”通常是指物理应用程序分离，例如客户端层和服务器层。
MVC - 指的是 3 个“层”，关注点是围绕 3 个关注点分离，它详细说明了模型（数据）、视图（UI）、控制器（应用逻辑）。
既然我已经对我的术语做出了区分..
在 mvc 应用程序中使用单独的数据访问应用程序是否过大？
我会说不（再次取决于您的应用程序的意思），这不是矫枉过正，因为它实际上可能会导致更易于维护的系统。您的 ORM可能会允许插入新的数据访问选项，但是如果您希望添加新的 ORM 怎么办？拥有一个明确分离的数据访问层 (DAL) 将使您的应用程序在这方面具有更大的未来灵活性。
另一方面，根据应用程序的规模和愿景，创建一个完全独立的数据访问选项可能是矫枉过正，但简而言之，将 DAL 分离到不同的程序集是在应用程序的组合中非常推荐的做法MVC 模式。
希望这会有所帮助，如果您需要更深入的评论。
好吧，我想这在一定程度上取决于您是在谈论层（物理）还是层（逻辑/项目）。
关于分层 - 您可以查看 s#arp 架构 ( code.google.com/p/sharp-architecture/ ) 之类的示例，了解他们如何做到这一点（他们采用了相当大的分层方法）。
有关此处更简约视图的示例，请查看 Ayende 的博客：ayende.com/Blog/
关于层 - 我认为不必要地添加额外的层并将所有东西都放在网络上只会影响您的性能，除非您出于容量原因需要这样做。正确设置层，并在您需要调整容量时将它们分成 teirs（如果您已经很好地分离了您的关注点，则不应进行太多重构）。
伟大的评论托拜厄斯。
我说添加足够多的层，以便它对您有意义并且更容易维护。还要保持关注点的分离。