什么是中型，高流量网站的最佳架构？

Question

我正在开始一个新项目（非法人），我想知道现在如何成为一个伟大的建筑。

我现在计划的是使用：

• ASP.NET MVC 4.0
• SQL Server 2008或2012
• 在.NET 4.5下的EF 5.0，使用Dapper
• 存储库模式的实现（这一个http://code.google.com/p/ef4prs/）
• DI与Autofac
• Automapper
• WCF服务层（用于未来的移动实施）

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

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

最后，我不知道这种架构是不必要的，还是只是穷人。

这是一个很多问题，但重点是要知道一个伟大而不是“过度架构”的解决方案，适用于中型网站。

对不起英文

Answer 1

您的问题相当主观，因为有许多可能的配置都能很好地运作。我可以给你一些建议。

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

事后来看，我建议选择一个并坚持下去。在.NET 4.5下，EF应该非常快。不像Dapper那么快，所以纯粹的Dapper路线并不是一个糟糕的路线。

您可以考虑的其他技术：

• ServiceStack（webservice）http://www.servicestack.net/。强烈推荐，配置低，快速且易于使用。
• ASP.NET MVC Web-API（webservice）http://www.asp.net/web-api。我没有经验。
• ThisMember（mapper，免责声明：我自己的图书馆）https://github.com/JulianR/ThisMember/wiki。比AutoMapper快很多（10-100倍），在我看来更容易使用。