三层体系结构中的SQL依赖关系和SignalR

我们有一个Web应用程序，它由一个带UI的3层后端（Controller/Biz/Data）组成。我们的数据层负责将数据从数据库实例（SQL）中提取出来，业务层将消息发送到数据并创建派生属性，控制器负责将这些更改发送到UI。三层体系结构中的SQL依赖关系和SignalR

我们需要在应用程序中实时更新必须在数据库级别（而不是控制器级别）进行跟踪。

我们选择使用SQL Dependency和SignalR作为我们的解决方案。

我研究过的关于SignalR和SQL依赖关系的一切都在数据库级别，SQL依赖性将在数据层内识别更改和广播。由于显而易见的原因，此方法将绕过在业务层中创建的派生属性，并给我们一个不同的外观对象。

我能想到的唯一解决方案是使用SQL Dependency跟踪更改，将它们转储到某个表/对象中，然后使用轮询从控制器，到biz层，到数据层获取这些更改，然后备份。

问题1：有没有更好的解决方案？
问题2：什么是包含业务层逻辑的最佳解决方案，但仍然能够跟踪数据层的更改？
问题3：这可能没有投票吗？

来源

2016-01-06 mtsuggs

SqlDependencyleaves垃圾在您跟踪的数据库中，并且不会自行清理。避免使用它！使用开源实现，而不是 - SqlDependencyEx。这是很容易配置和使用：

// See constructor optional parameters to configure it according to your needs 
var listener = new SqlDependencyEx(connectionString, "YourDatabase", "YourTable"); 

// e.Data contains actual changed data in the XML format 
listener.TableChanged += (o, e) => Console.WriteLine("Your table was changed!"); 

// After you call the Start method you will receive table notifications with 
// the actual changed data in the XML format 
listener.Start(); 

// ... Your code is here 

// Don't forget to stop the listener somewhere! 
listener.Stop();

通过上面你提到的，甚至可以跟踪实际成分改变的数据，您可以从事件处理程序的事件参数得到。希望这可以帮助。

来源

2016-01-09 02:03:21 dyatchenko

这不能解决我的问题，因为这种类型的代码/逻辑不应该在业务级别。业务级别不应该意识到任何涉及该模式的内容，只应该在DTO上工作。 – mtsuggs

为了什么目的？那么你可以坐下来欣赏，你保持了三层概念，而牺牲一个解决方案？我们使用这些工具来解决问题。并非每个问题都适合我们都喜欢这个十年的设计模式的最新理念。你有一个解决方案，所以你模糊你的控制器和业务层。大不了。只要保持视图或最终用户不受直接数据访问的影响，您仍然是个好主意。 – Jason

您的数据层捕捉数据库引发的事件。让它将数据映射到合适的DTO中，然后引发一个事件以被业务层捕获。业务层然后可以将事件引发到可以执行SignalR Broadcast（）的View层。冒泡！

来源

2017-08-02 22:02:43 REngber

三层体系结构中的SQL依赖关系和SignalR

回答

相关问题