如何设计一个能够显示最近事件的事件接收器

发布于 2024-11-29 05:52:37 字数 119 浏览 0 评论 0 原文

meetup 的主页在页面右侧显示了近期聚会的信息。您将使用什么样的设计模式/工具(首选基于java)来实现这样的输出。

The home page of meetup shows information on the recent meetups on the right hand side of the page. What kind of design patterns / tools (pref java based) would you use to implement such an output.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

天生の放荡 2024-12-06 05:52:37

有几种不同的方法,您使用哪一种取决于多种因素,包括业务流程的复杂性、所需的灵活性程度和负载。

简单的解决方案

  • “RSVP更新”在“RSVP”过程中直接写入某些数据源;这个过程本质上是硬编码的。
  • 有一些东西可以直接从它们所在的任何数据源/表中读取 RSVP。
  • 如果负载和数据量过多,此解决方案将很好。关键点是 RSVP UI 小部件最终将数据从与写入更新的数据源相同的数据源中拉出。

性能

一些不同的选项,基于以上内容作为起点:

  • 将数据保存两次:一次在 RSVP 数据的“主”(事务)表中,一次在为服务于 RSVP 数据而构建的表中。 UI(基本上是 OLTPOLAP)。第二个表将包含所有相关数据,以便无需查找其他表,并且由于它是数据的独立副本,因此您可以根据需要以不同方式管理它(例如:清除旧记录,以便表尺寸保持较小)。
  • 或者,不使用第二个表,而是将所有数据保留在内存中。这将要求您在内存中的副本丢失时从主事务表中提取数据。

灵活性

  • 与原始方法相同,但不是在记录 RSVP(到单个数据源)的步骤中进行硬编码,而是使用更松散耦合的方法,以便您可以添加/更改/删除多个事件处理器,如您所愿。一个将 RSVP 数据写入主 RSVP 数据源,而第二个将执行相同/相似的操作,但已聚合准备好
    “最近回复”UI 小部件。
  • 依赖注入将为您提供灵活性——当然,如果您处理事件处理程序的单个实现。
  • 发布/订阅或责任链模式可能为您提供一种方法的基础。

这就是你想要的信息吗?

There's a couple of different approaches, which one you use would depend on several factors including the complexity of the business processes, the degree of flexibility desired and load.

Simple Solution

  • "RSVP Updates" are written directly to some data source during the "RSVP" process; this process is essentially hard-coded.
  • Have something that reads out the RSVP directly from the whatever data source / table they live in.
  • This solution will be fine if the load and data volumes are excessive. The key point is that the RSVP UI widget ends up pulling the data out of the same data source as where the updates are written to.

Performance

A few different options, based on the above as a starting point:

  • Hold the data twice: once in the "master" (Transactional) table of RSVP data, and once in a table built for servicing the UI (Basically OLTP vs OLAP). The second table would include all the relevant data so that there were no look-ups to other tables, and as it's an independent copy of the data you can manage it differently if you want to (for example: purge out old records so the table size is kept small).
  • Or, instead of a second table just keep all the data in memory. this would require you to pull the data out of the main transactional table whenever the in memory copy is lost.

Flexibility

  • Same as the original approach but instead of hard-coding in the step that records the RSVP (into a single data source) use a more loosely-coupled approach so that you can add / change / remove as many event processors as you wish. One will write the RSVP data to the main RSVP data source, while a second will do the same/similar but aggregated ready for the
    "Recent RSVPs" UI Widget.
  • Dependency Injection will give you the flexibility - certainly if you deal with a single implementation of the event handler.
  • The Publish / Subscribe or Chain of Responsibility patterns might give you the basis of an approach.

Is that the kind of info you were after?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文