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