什么是中型、高流量网站的最佳架构？ [关闭]

Question

我正在开始一个新项目（非公司），我想知道现在如何成为一个伟大的架构。

我现在打算使用：

• ASP.NET MVC 4.0
• SQL Server 2008 或 2012
• .NET 4.5 下的 EF 5.0，带有 Dapper
• Repository模式的实现（这个http://code.google.com/p/ef4prs/）
• DI 与Autofac
• 自动映射器
• WCF 服务层（用于未来的移动实施）

检查流程（如果有问题请纠正我）：Controller 调用 ApplicationService，调用 BusinessLayer，调用 DAL 与 UnitWork/Repository，通过 EF 或 Dapper 执行查询（从 Repository 的特定方法查询 Dapper 是否正确？），然后是结果自动映射到 DTO 并返回到 Controller，将所需内容复制到 ViewModel 并返回 View。

这里的问题是性能，正如我所说，该网站计划有高流量。 在这种情况下，上面列出的任何项目都会降低性能吗？还是这种组合泄漏了更多东西？ 我应该丢弃 EF，只使用 Dapper 吗？ 恐怕服务层会因为流量而降低性能。

最后，我不知道这种架构是不必要的，还是很差。

这是很多问题，但重点是了解适合中型网站的出色而不是“过度架构”的解决方案。

对不起英语

Answer 1

您的问题相当主观，因为有许多可能的配置都可以正常工作。不过我可以给你一些建议。

将 EF 与 Dapper 混合和匹配可能有点雷区。理论上，您应该能够使用 Dapper 获取对象，然后将 Attach 它们发送到 DbContext 并更新它们。但是，根据我的经验，这通常不起作用。我们从 EF 开始，然后慢慢转移到 Dapper 进行快速查询，我认为我们可以继续使用 EF 进行更新/插入，但我最终推出了自己的插入/更新跟踪（非常简单），因此我们正在慢慢淘汰EF的使用。

事后看来，我建议选择一个并坚持下去。 EF 在 .NET 4.5 下应该相当快。虽然不如 Dapper 快，所以纯粹的 Dapper 路线也不错。

您可以考虑的其他技术：

• ServiceStack（网络服务）http://www.servicestack.net/。强烈推荐，低配置，快速且易于使用。
• ASP.NET MVC Web-API（网络服务）http://www.asp.net/web-api。我没有这方面的经验。
• ThisMember（映射器，免责声明：我自己的库）https://github.com/JulianR/ThisMember/wiki。在我看来，它比 AutoMapper 快很多（10-100 倍）并且更易于使用。