我正在开发当前基于以下架构构建的项目:
1)第一个解决方案
- 具有基于 Entity Framework 5 的所有数据库逻辑 (DAL) 的项目
- WebAPI 项目负责向客户门户网站和智能手机应用提供数据
2)第二种解决方案
- 充当客户门户网站的 MVC4 项目
客户门户网站和 WebAPI 位于同一服务器上。 WebAPI 直接访问数据库,而 Customer Web Portal 通过 WebAPI 访问数据库。选择此架构的原因是为了缩短开发时间,因为 Web 门户和智能手机应用程序调用 85% 的相同 Web 服务。然而,我非常担心这个架构的性能有多好。我认为客户门户网站应该直接访问数据库,这将是更有效的方式。
对此有什么想法吗?
最佳答案
架构总是很棘手的,它总是需要在开发速度、可维护性、性能和可扩展性等不同因素之间进行折衷。因此,您需要权衡所有利弊。
通过WebAPI访问数据库
1.肯定会带来一些性能开销。但多少钱呢?假设通过额外的包装器 (WebAPI) 传递调用将导致每次调用花费大约 2-3 毫秒的额外时间,以及总共大约 200MB 的额外 RAM。我认为,这不是一个真正的问题,但你更了解所有细节,这取决于你。
2.该解决方案可以从使用缓存中获得一些好处。如果您将 IIS 配置为缓存对 WebAPI 的请求,则 WebAPI 客户端和门户都将提高性能。
直接通过DAL访问DB
1.从理论上讲,您将向需要处理的数据库引入两个入口点。如果您需要添加一些必须由 WebAPI 客户端和门户使用的逻辑,并且该逻辑是特定于 Web 的(例如,与用户 session 相关的逻辑),该怎么办?您不应该将其添加到 DAL,而是需要使用另一个库添加另一个层,该库将由 WebAPI 和您的门户使用。如果您唯一的访问点是 WebAPI,那么您可以仅修改 WebAPI 来获取结果。
总结:
这些只是一些优点和缺点。但是,如果您的项目规模不大,如果不打算承受很高的负载,那么我会考虑的唯一因素就是开发成本。如果使用 WebAPI 作为单一入口点更快,那么就使用它。
关于c# - Web 门户从 Web 服务或数据库获取数据 - 架构模式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13431390/