繁体   English   中英

Web 门户从 Web 服务或数据库中获取数据 - 架构模式

[英]Web portal taking data from web service or database - architecture pattern

我正在研究当前基于以下架构构建的项目:

1)第一个解决方案

  • 具有基于 Entity Framework 5 的所有数据库逻辑 (DAL) 的项目
  • WebAPI 项目负责向客户 Web 门户和智能手机应用程序提供数据

2)第二种解决方案

  • 作为客户 Web 门户的 MVC4 项目

客户 Web 门户和 WebAPI 位于同一台服务器上。 WebAPI 直接访问数据库,而客户门户网站通过 WebAPI 访问它。 选择此架构的原因是为了缩短开发时间,因为 Web 门户和智能手机应用程序正在调用 85% 的相同 Web 服务。 但是,我非常担心这是多么好的性能架构。 我认为客户 Web 门户应该直接访问数据库,这将是更有效的方式。

对此有何想法?

架构总是很棘手,它总是在不同的因素之间做出妥协,比如开发速度、可维护性、性能和可扩展性。 所以,你需要权衡所有的利弊。

通过 WebAPI 访问数据库

1 . 肯定会引入一些性能开销。 但是多少钱? 假设通过额外的包装器 (WebAPI) 传递您的调用,每次调用将花费您大约 2-3 毫秒的额外时间,并且总共需要大约 200MB 的额外 RAM。 我认为,这不是一个真正的问题,但您更了解所有细节,这取决于您。

2 . 该解决方案可以从使用缓存中获得一些好处。 如果您将 IIS 配置为缓存对 WebAPI 的请求,那么:WebAPI 客户端和门户都会提高性能。

直接通过 DAL 访问数据库

1 . 从理论上讲,您要为您的数据库引入两个需要处理的入口点。 如果您需要添加一些必须由 WebAPI 客户端和您的门户使用的逻辑,并且该逻辑是特定于 Web 的(例如,与用户会话相关的某些内容),该怎么办? 您不应该将它添加到 DAL,而是需要使用另一个库添加另一个层,该库将被两者使用:WebAPI 和您的门户。 如果您唯一的访问点是 WebAPI,那么您只需修改 WebAPI 即可获得结果。

总结一下:

这些只是一些优点和缺点。 但是如果你的项目不是很大,如果它不打算承受很高的负载,那么我会考虑的唯一因素就是开发成本。 如果将 WebAPI 用作单个入口点会更快,那么就使用它。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM