MVC使用中的两个问题

[公西雒]

1.两个不同的MVC项目A和B，B需要实时同步A的用户基本信息，A需要实时同步B的消费信息（如金额，积分等）。
我想到的是做接口，A在用户注册或修改用户信息时，调用B的用户信息接口，B中用户在消费时，调用A的消费信息接口；或者只在A中做接口，B去轮询。
2.如果要轮询接口，那么这个轮询的方法应该写在哪层？是controller还是其他地方？一直没想到合适的地方。 而且还要保证轮询一直可用。
请给出设计思路，谢谢！

[公西雒]

引用 5 楼 xiaojie_cp 的回复:

互相公开接口互相调用不行吗

行，想知道是不是最优的设计思路。

[newtee]

用个消息队列解耦 A发布 B订阅

[skydhx]

互相调用，直到同步了才不请求！

[正怒月神]

如果要 轮询的话，那么在view页面添加ajax和settimeout函数去调用webapi

[公西雒]

引用 7 楼 zhuankeshumo 的回复:

用个消息队列解耦 A发布 B订阅

订阅是怎么回事？

引用 9 楼 hanjun0612 的回复:

如果要 轮询的话，那么在view页面添加ajax和settimeout函数去调用webapi

但是我想在后端轮询啊，需要系统自动轮询，而不要人去操作。

[xdashewan]

引用 4 楼 danding_ge 的回复:

没有其他后台服务，直接在AB两个项目中，数据库不能联系，不能互相访问，同步就是简单的增删改查。接口就是提供个网址，数据是json格式。可以脱离网站，但是我不想脱离网站再去建个新项目，增加工作量。

没有最佳方式，只有最合适的方式。例如如果你数据库能相互访问，那么订阅发布就是最适合的方式。鉴于你现在的描述，我个人觉得轮询方式要比主动推送要适合。原因是你说接口就是提供个网址，那么就是走HTTP方式，HTTP方式有个缺点就是你如果想取对方成功与否的返回值，你势必需要等待，这会消耗时间。当然你说提供异步回掉，那么你也必须去增加异步回调后如果结果是错误时的重发机制。而轮询只需要重新获取一次。

[娃都会打酱油了]

实时的话不应该是a主动调用b公开的接口吗？也就是推模式，b从a站拉感觉不是很适合你的需求

[xdashewan]

很多情况还是不明，比如AB两个项目数据库是直接在MVC项目中访问，还是另外有提供类似WCF的其他后台服务？两个数据库之间是否有联系？能否相互访问？同步过程中是否要做复杂的逻辑处理？在两数据库能相互访问，也没有复杂逻辑处理的情况下，做订阅发布能够满足需求，还是有一些特殊要求？AB的接口分别以什么形式公布？轮询是否有条件脱离网站，独立后台运行？

[公西雒]

引用 1 楼 starfd 的回复:

实时的话不应该是a主动调用b公开的接口吗？也就是推模式，b从a站拉感觉不是很适合你的需求

按照我的第一个想法就是推的，第二个是拉。

[公西雒]

引用 2 楼 xdashewan 的回复:

很多情况还是不明，比如AB两个项目数据库是直接在MVC项目中访问，还是另外有提供类似WCF的其他后台服务？两个数据库之间是否有联系？能否相互访问？同步过程中是否要做复杂的逻辑处理？在两数据库能相互访问，也没有复杂逻辑处理的情况下，做订阅发布能够满足需求，还是有一些特殊要求？AB的接口分别以什么形式公布？轮询是否有条件脱离网站，独立后台运行？

没有其他后台服务，直接在AB两个项目中，数据库不能联系，不能互相访问，同步就是简单的增删改查。接口就是提供个网址，数据是json格式。可以脱离网站，但是我不想脱离网站再去建个新项目，增加工作量。

[lovebaby]

互相公开接口互相调用不行吗

[公西雒]

引用 11 楼 xdashewan 的回复:

[quote=引用 4 楼 danding_ge 的回复:] 没有其他后台服务，直接在AB两个项目中，数据库不能联系，不能互相访问，同步就是简单的增删改查。接口就是提供个网址，数据是json格式。可以脱离网站，但是我不想脱离网站再去建个新项目，增加工作量。

没有最佳方式，只有最合适的方式。例如如果你数据库能相互访问，那么订阅发布就是最适合的方式。鉴于你现在的描述，我个人觉得轮询方式要比主动推送要适合。原因是你说接口就是提供个网址，那么就是走HTTP方式，HTTP方式有个缺点就是你如果想取对方成功与否的返回值，你势必需要等待，这会消耗时间。当然你说提供异步回掉，那么你也必须去增加异步回调后如果结果是错误时的重发机制。而轮询只需要重新获取一次。[/quote] 按我的理解，轮询是客户端以一定的时间间隔向服务端发出请求，以频繁请求的方式来保持客户端和服务器端的同步。但是为什么你说轮询只需要重新获取一次？

[以专业开发人员为伍]

我只随便从概念出发给你回复一点吧。 后台系统数据处理，跟什么 MVC 半点关系都没有，MVC 是那些一遍遍刷新界面的前端系统的模式。因此你的疑惑可以理解，但是也其实很容易回答，就是不要扯上什么前端模式。假设你写代码都是模仿入门书上的 MVC 界面程序的例子，现在要临时弄个数据访问来”顶一下“，那么你自然顶多也就是写在 Controller 部分，因为这个地方是接受客户端访问的部分，就好像政府办事大厅的”首问负责制“一样，再往深层追究就更加混乱了。 而实际上对于一个真正的内部数据服务，放到 Controller 肯定也是不对的。因为就是接入前端页面请求的，真正的核心服务系统的底层叫做 windows service，而不是什么 asp.net。

[公西雒]

引用 13 楼 sp1234 的回复:

我只随便从概念出发给你回复一点吧。 后台系统数据处理，跟什么 MVC 半点关系都没有，MVC 是那些一遍遍刷新界面的前端系统的模式。因此你的疑惑可以理解，但是也其实很容易回答，就是不要扯上什么前端模式。假设你写代码都是模仿入门书上的 MVC 界面程序的例子，现在要临时弄个数据访问来”顶一下“，那么你自然顶多也就是写在 Controller 部分，因为这个地方是接受客户端访问的部分，就好像政府办事大厅的”首问负责制“一样，再往深层追究就更加混乱了。 而实际上对于一个真正的内部数据服务，放到 Controller 肯定也是不对的。因为就是接入前端页面请求的，真正的核心服务系统的底层叫做 windows service，而不是什么 asp.net。

两个服务器后台数据的互相传输，要怎么设计系统服务呢？

[以专业开发人员为伍]

引用 4 楼 danding_ge 的回复:

没有其他后台服务，直接在AB两个项目中，数据库不能联系，不能互相访问，同步就是简单的增删改查。接口就是提供个网址，数据是json格式。可以脱离网站，但是我不想脱离网站再去建个新项目，增加工作量。

对于你的 1. 的方案，你认为数据需要”推“那就推呗，并且你认为访问网站，那就访问网站呗，或者你认为网站的数据服务service就等于 Controller，那就跟你的网页的 Controller 也写到一块儿呗。反正混在一起的做法，初开始时都觉得很爽。其实对于你的1.方案就没有太多可说的，只有细节才会出问题，而逻辑上它本来就是一个”实时“方案，不像你的 2. 根本不是一个实时可行方案。

[以专业开发人员为伍]

另外，假设两个网站离的很远，而需要同步的信息的并发量很大，以至于不可靠的 http、慢速的 http 成了瓶颈，那么可能就需要彻底重构，从是否需要才用高效率且可靠的消息协议、长连接还是短链接、并发量、“单纯推数据还是推拉结合”、能不能在下一次同步时自动补充上一次未同步成功的数据、操作是否具有迷瞪行，等等方面，进行设计。

[以专业开发人员为伍]

迷瞪行 --> 幂等性 windows service 是常驻操作系统服务的，一个几十行业务处理代码的专门用户数据同步的windows service，如果它与 asp.net 网站想分离，可以保证稳定、高并发（本地asp.net只需要写3、4行代码访问一下本地的数据同步服务，就不用管后续操作了）、支持同步续传问题，等等。 不过如果你现在站在 asp.net 网站编程的角度，那么你还是从你的 1. 方案着手，解决眼前问题。最近几年的互联网时代其实就是江湖，各种前端开发人员都来做主程序员，天使投资人只信自己的眼睛。

[丰云]

什么接口，什么轮询，什么同步都不需要，只要两个系统共用一个缓存，所谓的用户信息，所谓的消费信息，都写入同一个缓存，读取也如此，所有问题都解决了！！！ 程序员最重要的财富不是技术，是灵活的头脑，技术只是基本的门槛

[公西雒]

其实我要的是Hangfire这种东西，好吧，今天终于找到答案了，结贴了。