制作一个 Web 程序来连接与数据库无关的层是否明智？
我以前是一名Winforms程序员；我总是将编写的程序分为两部分，前端（Winforms）和中间层（由Remoting/WCF促进）
在这种方法中，前端代码无法访问Linq或System.Data.SqlClient。但这还有一个额外的优势，即中间层是即时 SOA 公民（面向服务的架构），可以在 B2B 场景中使用，与数据库无关，并且支持 Internet，即使它只是一个 Winforms 应用程序。
现在我正在学习网络技能。使用《Pro ASP.NET MVC》一书中的 SportsStore 项目，我不可避免地会比较我的旧（？）方法（中间层）和该书中的存储库方法。存储库方法直接在前端（SportsStore.WubUI）上公开数据访问机制（Linq to SQL）。使用存储库方法，SportsStore.WebUI 仍然可以直接连接到数据库。
问题是，在 Web 程序上，我是否应该渴望让前端仅与中间层交互（因此前端可以与数据库无关，而中间层是即时的 SOA 公民），还是应该在前端直接使用数据库（通过存储库方法、ORM 或类似方法）？
I'm a Winforms programmer before; I always partition programs I write in two parts, the front-end(Winforms) and middle-tier(facilitated by Remoting/WCF)
On that approach, the front-end code cannot access the Linq or System.Data.SqlClient. But that has the added advantage that the middle-tier is an instant SOA-citizen (service oriented architecture), can be used in B2B scenarios, database-agnostic, and internet-capable even it's just a Winforms app.
Now I'm learning web skills. Using the SportsStore project from the book Pro ASP.NET MVC, it's inevitable that I would compare my old(?) approach (the middle-tier) and the repository approach on that book. The repository approach exposes the data access mechanism(Linq to SQL) directly on front-end(SportsStore.WubUI). Using the repository approach, the SportsStore.WebUI still has a direct connection to database.
Question is, on web programs, should I aspire making the front-end to interface only to a middle-tier(so the front-end can be database-agnostic and the middle-tier is an instant SOA-citizen), or should I use the database directly(by means of repository approach, ORM, or similar) on front-end?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我确信为了简洁起见，这本书违反了一些最佳实践。作者必须平衡“我如何表达我的观点”与“正确的方法是什么”；他们通常选择前者（他们应该这么做——这是一本关于 Web 开发的书，而不是关于架构的书，对吧？）。
您绝对应该继续使用 n 层架构。 n 层架构的全部要点是允许您（更）轻松地交换各层 - 切换数据库、切换用户界面（例如，用 ASP.NET 替换 Winforms）。
I'm certain that the book has violated some best practices for the sake of brevity. Authors have to balance "how do I get my point across" versus "what is the correct way to do it"; they usually opt for the former (as they should -- this is a book about web development, not about architecture, right?).
You should absolutely continue to use n-tier architectures. The whole point of the n-tier architecture is to allow you to (more) easily swap out the layers -- switch databases, switch user interfaces (replace Winforms with ASP.NET, for example).