MVC/MVP 中的控制器间通信
MVC/MVP 中松耦合控制器间通信的好方法是什么？
例如，在报价中，用户必须创建并添加新联系人，或添加现有联系人。
他们选择创建新联系人。完成后，联系人将添加到报价中，并且 UI 将用户返回到该报价。如果他们点击取消，则会返回报价。
我想在其他地方重用 Contact，因此它不应该知道有关 Quote 的任何信息。例如，如果我从联系人列表中创建联系人，则完成后它应该返回那里。
以下是我想到的一些选项：
ContactsController 操作调用 ApplicationController.getNextStep(this) 并且 ApplicationController 代表 ContactsController 计算出下一步
ContactsController 引发“actioncomplete”事件或类似事件，并且 ApplicationController 正在侦听此事件，并调用正确的下一步
QuoteController 将“接力棒”传递给 ContactsController 进行下一步，ContactsController 在完成时调用该步骤
ContactsController 引发“actioncomplete”事件或类似事件，并且 QuotesController 正在侦听此事件，并调用正确的下一步。
你有这些经验吗？还有其他想法吗？在大型应用程序中，哪个会引起最少的麻烦？
谢谢！
What is a good method for loosely-coupled inter-controller communication in MVC/MVP?
For example, in a Quote, the user must create and add a new contact, or add an existing one.
They choose to create a new contact. When complete, the contact is added to the quote, and the UI returns the user to that quote. If they hit cancel, they are returned to the quote.
I want to re-use Contact elsewhere, thus it should not know anything about Quote. For example, if I create a contact from the contacts list, it should return there when done.
Here are some options that I have thought of:
ContactsController action calls ApplicationController.getNextStep(this) and the ApplicationController figures it out the next step on behalf of the ContactsController
ContactsController raises "actioncomplete" event or similar, and the ApplicationController is listening for this event, and calls the correct next step
QuoteController passes in a "baton" to ContactsController with the next step, which ContactsController calls when done
ContactsController raises "actioncomplete" event or similar, and the QuotesController is listening for this event, and calls the correct next step.
Do you have experience with these? Other ideas? Which will cause the fewest headaches in a big app?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以实现某种形式的导航堆栈，其中首先将报价或联系人控制器推入其中，然后在需要时将联系人控制器推入其中。当接触控制器完成后，它会自动弹出并在下一个控制器处达到峰值，以知道该去哪里。这样它就完全解耦了，可以在任何地方重用，并且可以嵌套n层深度。
You could implement some form of navigation stack, where the Quote or Contacts controllers are first pushed into it, and then they push the Contact controller into it when required. When the Contact controller is done, it pops itself off and peaks at the next one to know where to go. This way it is completely decoupled and can be re-used everywhere, and can be nested n-levels deep.
如果我正确理解您的问题，那么您有一个由控制器巧妙封装的操作，并且您希望确保其执行后行为可以尽可能动态地定义。
您对回调函数的想法非常好，但我会更进一步，将其设为 Func<>，允许您使用闭包。我将扩展您的顾问比喻：不要将电话号码传递给您的代表，而是让他连接回办公室并从那里获取指示。使用闭包的优点在于，您可以直接从代码访问调用上下文，否则超出范围；换句话说，闭包可以访问主控制器中的所有变量和函数。
当你的推销员完成他的任务时，他只需打开公文包 (Func<>) 并把手伸进他的办公桌办公室，看看是否有人在他的办公室抽屉里放入了待办事项。
Jon Skeet（也在 StackOverflow）在这里有一个很棒的资源：http://csharpindepth.com/articles/ Chapter5/closures.aspx
If I understand your question correctly, you have an action neatly encapsulated by a controller, and you'd like to ensure its post-execution behavior can be defined as dynamically as possible.
Your idea of a callback function is very good, but I'd go a step further and make it a Func<>, allowing you to utilize closures. I'll expand on your consultant metaphor: instead of passing a phone number to your rep, instead have him connect back to the office and get instructions from there. The beauty of using closures is that you can access the calling context directly from code otherwise out of scope; in other words, the closure can access all of the variables and functions in the host controller.
When your salesman is done with his task, he merely opens his briefcase (Func<>) and reaches into his desk at the office to see if anyone has put a To-Do item in his office drawer.
Jon Skeet (also on StackOverflow) has a great resource here: http://csharpindepth.com/articles/chapter5/closures.aspx
我想我会回答我自己的问题。希望我能得到那份甜蜜的赏金。
从派遣顾问员工去见客户的角度来思考这个问题。他知道如何做他的工作，但他不知道完成后该做什么。你希望他对下一步做什么保持灵活。
有时他的老板会派他出去。有时首席执行官会这样做（他可能不知道之后要派他去哪里）。有时客户会因紧急情况打电话给他（他肯定不知道之后该把他送到哪里）。有时他只是从白板上抓取一个新任务。
他可以做以下几件事之一：
您可以告诉他在完成后给总部打电话，总部会为他解决这个问题。他不需要知道任何其他人，只需要知道总部的电话号码。
你可以在他完成后、离开之前告诉他该做什么。如果他离开一段时间，他的下一个任务可能会同时发生变化。
你可以告诉他完成后发布到Facebook，总部会寻找它，并告诉他该怎么做。总部需要监视所有顾问的大量 Facebook 帖子。
您可以告诉他的主管在他完成工作后接听他的电话，但随后他的主管需要在办公室，也许他会更换主管。
就我个人而言，我会传递一个回调函数。如果该回调为空，则被调用者应询问应用程序要做什么。这为您提供了一定的灵活性，同时还允许父进程来管理事物，而不是依赖于应用程序中的一项大功能。
这相当于当顾问完成工作后，向他提供下一个要致电的客户的电话号码。如果他没有得到电话号码，他就会给总部打电话。
您也可以使用事件，这不是一个坏主意。唯一的问题可能是，如果多个对象正在侦听此事件，则可能会发生一些意外情况。
Guess I will answer my own question. Hopefully, I get that sweet, sweet bounty.
Think about this from the perspective of sending your consultant employee out to a customer. He knows how to do his job, but he doesn't know what to do when he's finished. You want him to be flexible about what he does next.
Sometimes his boss sends him out. Sometimes the CEO does (he might not know where to send him after). Sometimes the client calls him in with an emergency (he definitely doesn't know where to send him after). Sometimes he just grabs a new task from the whiteboard.
He could do one of several things:
you could tell him to call the head office when he's done, and head office will figure it out for him. he doesn't need to know about any other people, just the head office phone number.
you could tell him what to do when he's finished, before he leaves. if he's gone for a while, his next task might have changed in the meantime.
you could tell him to post to facebook when he's done, head office will be looking for it, and will tell him what to do. head office would need to be watching for a lot of facebook posts from all their consultants.
you could tell his supervisor to to answer his call when he's finished, but then his supervisor needs to be in the office, and maybe he'll switch supervisors.
Personally, I would pass in a callback function. If that callback is null, the callee should ask the application what to do. That gives you some flexibility, while also allowing for a parent process to manage things, and not relying on one big function in the app.
This would be equivalent to giving the consultant the number of the next customer to call, when he's done. If he doesn't get a number, he calls the head office.
You could use an event as well, and it's not a bad idea. The only issue might be if multiple objects are listening for this event, something untoward might happen.