什么是组合存储库和服务总线？ [英] What is a Combo Repository and a Service Bus?

问题描述

我正在学习有关NoSQL以及DynamoDB的更多信息。我最近问了这个问题：将数据库结构从SQL Server映射到DynamoDB

在已接受答案下的评论中；答案是指服务总线和组合库。

Q1）这是服务巴士吗？ （请参阅EventListener类）： http：/ /enterprisecraftsmanship.com/2015/05/06/combining-sql-server-and-mongodb-using-nhibernate/

Q2）什么是组合仓库？它是组合存储库，即某些方法与多个数据库（SQL Server和DynamoDB）接口吗？

我通常会问答案，但是我们开始从其他问题的原始帖子-回答者提到了这一点。因此，我决定问另一个问题。

解决方案

我正在考虑使用NoSQL数据库来规模数据库读取

好主意。听起来您正在沿着命令查询责任隔离（CQRS）的路径前进。

链接描述了一种使用NHibernate更新
组合SQL Server和MongoDB的技术-这就是我所说的组合（组合）存储库。 组合存储库不是标准模式。引用作者：

当然，从理论上讲，我们可以将所有数据移至某个NoSQL存储中，但是如果不这样做，该怎么办？是否想完全摆脱我们的关系数据库？我们如何组合它们在一起？

您已经用两个<$ c标记了原始问题$ c> Sql-Server 和一个 NoSql 数据库，因此猜测您在多边形空间

存储库模式是围绕数据持久性的非常常见的抽象层。

组合链接您所引用的内容专门解决了多对多关系（在Sql中通常称为Junction表）的问题，以及在存在许多此类关系时对性能的影响。

从更一般的意义上讲，作为在NHibernate中提供拦截点的替代方法，您可能/可能没有通过存储库模式进行抽象数据访问。

简单（非地理） neric）C＃中的存储库接口：

 公共接口IWidgetRepository 
 {
 Task< Widget> FetchWidget（string widgetKey）; 
 Task SaveWidget（Widget toBeSaved）; 
} 
  

假设我们已经有一个SqlRepository：

 公共类SqlWidgetRepository：IWidgetRepository 
 {
 public async Task< Widget> FetchWidget（string widgetKey）
 {
 ...使用代码以获得NHibernate会话并检索和反序列化Widget 
} 
 ...此处的其他方法
} 
  

您还可以选择提供 MongoDb 实现

 公共类MongoWidgetRepository：IWidgetRepository 
 {
 public async Task< Widget> FetchWidget（string widgetKey）
 {
 ...用于连接到MongoDb辅助数据库并查找（）
小部件并反序列化为Widget 
} 
的代码...这里的其他方法
} 
  

并同时维护两个数据库，这是一个示例 combo存储库可能看起来像：
私有只读IWidgetRepository _repo2;

public ComboWidgetRepository（IWidgetRepository repo1，IWidgetRepository repo2）
{
repo1 = repo1;
repo1 = repo2;
}

公共异步任务< Widget> FetchWidget（string widgetKey）
{
//只需要一个...第一个赢得
返回等待Task.WhenAny（repo1.FetchWidget（widgetKey），
repo2.FetchWidget （widgetKey））;
}

公共异步任务SaveWidget（Widget toBeSaved）
{
//需要同时保存两者
等待Task.WhenAll（repo1.SaveWidget（ toBeSaved），
repo2.SaveWidget（toBeSaved））;
}

上述 combo存储库很可能满足单个系统的需求（

但是CQRS经常在企业范围内使用（即，您的系统很多，数据库很多）。 / p>

我对企业服务总线的评论>仅在需要在整个企业中分发数据时才有意义。

概念很简单

• 命令在总线上排队到事务系统（例如添加小部件）。


• 您的系统处理小部件执行事务（例如将小部件插入数据库中） ）


• 然后，小部件系统向总线发布（广播）一条消息，详细说明已添加了新的小部件（所有相关的小部件信息）


• 其他她在企业中对微件的更新感兴趣的系统订阅了此消息，并将更新其自己的微件的 Read Store 表示形式（例如，


• 通过这种方式，当用户访问任何其他系统并查看有关小部件的屏幕时， ，系统可以从自己的读取存储中提供数据，而不必从 Widget 系统本身请求数据。

I am learning more about NoSQL and specifically DynamoDB. I recently asked this question: Mapping database structure from SQL Server to DynamoDB

In the comments under the accepted answer; the answers refers to a Service Bus and a Combo repository.

Q1) Is this a Service Bus? (see EventListener class): http://enterprisecraftsmanship.com/2015/05/06/combining-sql-server-and-mongodb-using-nhibernate/

Q2) What is a Combo repository? Is it a "Combination" repository i.e. some methods interface with multiple databases (SQL Server and DynamoDB).

I would usually ask the answerer, however we started to divert from the original post in the other question - the answerer mentioned this. Therefore I have decided to ask another question.

解决方案

I am thinking about using a NoSQL database to scale database reads

Good idea. It sounds like you are going down the path of Command Query Responsibility Segregation(CQRS). NoSql databases make for excellent read stores.

The link you referenced describes a technique to update Combining SQL Server and MongoDB using NHibernate - this is what I meant by 'Combo' (combining) Repository. "Combo Repository" isn't a standard pattern. Quoting the author:

Of course, theoretically, we could just move all the data to some NoSQL storage, but what if we don’t want to get rid of our relational database completely? How can we combine them together?

You've tagged your original question with both a Sql-Server and a NoSql database, so at a guess you're in the Polyglot space

The Repository Pattern is a very common abstraction layer around data persistence.

The "combining" link you've referenced specifically solves the problem of many-to-many relationships (often referred to as Junction tables in Sql), and the performance implications when there are many such relations.

In the more general sense, as an alternative to providing interception points in NHibernate, you may / may not have abstracted data access via the repository pattern.

Here's an ultra simple (and non-generic) repository interface in C#:

public interface IWidgetRepository
{
     Task<Widget> FetchWidget(string widgetKey);
     Task SaveWidget(Widget toBeSaved);
}   

Suppose we already have a SqlRepository:

public class SqlWidgetRepository : IWidgetRepository
{
     public async Task<Widget> FetchWidget(string widgetKey)
     {
         ... Code to use Obtain an NHibernate session and retrieve and deserialize Widget
     }
    ... Other methods here
}   

You could also choose to provide a MongoDb implementation

public class MongoWidgetRepository : IWidgetRepository
{
     public async Task<Widget> FetchWidget(string widgetKey)
     {
        ... Code to connect to a MongoDb secondary and Find() the 
           widget and deserialiaze into Widget
     }
    ... Other methods here
}   

And to maintain both databases simultaneously, here's an example of how this "combo" repository may look:

public class ComboWidgetRepository : IWidgetRepository
{
     private readonly IWidgetRepository _repo1;
     private readonly IWidgetRepository _repo2;

     public ComboWidgetRepository(IWidgetRepository repo1, IWidgetRepository repo2)
     {
          repo1 = repo1;
          repo1 = repo2;
     }

     public async Task<Widget> FetchWidget(string widgetKey)
     {
          // Just need the one ... first one wins
          return await Task.WhenAny(repo1.FetchWidget(widgetKey), 
                                    repo2.FetchWidget(widgetKey));
     }

     public async Task SaveWidget(Widget toBeSaved)
     {
          // Need both to be saved
          await Task.WhenAll(repo1.SaveWidget(toBeSaved), 
                             repo2.SaveWidget(toBeSaved));
     }

The above "combo" repository may well fulfil the needs of a single system (and there are many other ways to keep two databases synchronized).

CQRS is however frequently used at enterprise scale (i.e. where you have many systems, with many databases).

My comment about an Enterprise Service Bus will only make sense if you need to distribute data across an enterprise.

The concept is simple

• Commands are queued to a transactional system (e.g. "Add Widget") across the bus.
• Your system handling widgets performs the transaction (e.g. inserts the widget into a database)
• The Widget system then publishes (broadcasts) a message to the bus detailing that a new widget has been added (with all the relevant widget information)
• Other systems on in the enterprise which are interested in updates to Widgets subscribe to this message and will update their own Read Store representations of the Widgets (e.g. into a NoSql database or cache, and in the format which makes most sense to them).
• This way, when a user accesses any of these other systems and views a screen about 'Widgets', the system can serve the data from its own Read Store, instead of having to request the data from the Widget system itself.

这篇关于什么是组合存储库和服务总线？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！