标签: data-driven

我正在尝试用C++创建一个高效的"实体系统",我在互联网上阅读了很多博客/文章/文档以获取大量信息,但我又遇到了一些问题.

我发现了两个有趣的主题:

• 数据驱动系统
• 实体组件系统

对我来说,这两个系统看起来非常相似.

所以,我发现了Adam Smith的这个例子:https://stackoverflow.com/a/2021868

我需要一个像这样灵活的系统:

// Abstract class
class Component
{
     // data here
}

// exemple
class Car : public Component
{
    // Data here
}

// Entity with components
class Entity
{
   std::vector<Component*> components;
}

所以,如果我的实体有以下组件:Car,Transform,Sprite, 我的组件数组是否会有数据驱动系统等线性数据？

现在,我有系统:

class System 
{
     virtual void init();
     virtual void clear();
     virtual void update();

     std::unordered_map< const char*, Entity*> entities;
}

class RendererSystem : public System
{
    // Methods's definition (init, clear, …).

    void update()
    {
       for( …

上下文:在.NET平台上构建智能客户端应用程序,其中包含涉及大量列的复杂数据库模型.自然的应用程序风格是典型的数据驱动CRUD.在某些情况下,还有一些服务器端逻辑,以及一些复杂的验证.您可以完全控制客户端和服务器,因此对互操作性的需求至少是必需的.


这个问题有很多细节,为此道歉,但这是因为我想为答案设置适当的背景.


还有一些假设
- 在微软世界中并不罕见,大多数以前的应用程序都是用DataSet编写的,因此它是所涉及开发人员最熟悉的技术.但是,让我们说开发人员也非常精通OO思维.
- 您需要在客户端和服务器上运行验证.
- 您不以表格形式显示大多数数据.
- 这不是内联网应用程序,因此您不能过多地考虑带宽


最大的问题:数据集还是对象？

如果你选择数据集,你会有一些积极的和消极的
- 在积极方面:你从数据库中获取数据,通过网络获取数据并通过网络返回更改的数据方面获得了一些Microsoft支持较小的块 - 因为您只能指定发送更改.发送较少的数据是好的,因为可能涉及相当多的数据.
- 否定的是:在验证,业务逻辑等方面,你得到了一个程序化的代码形式,你没有得到面向对象代码的好处 - 行为和数据在一起,更自然的工作和思考方式你正在做什么,可能更接近验证逻辑.您还可以放弃将数据集放在网格中的好处,因为这不是常见的用例.

如果你去寻找对象,那就是同样的练习,但还有更多的选择:
肯定:行为和数据在一起.验证逻辑更接近.更容易查看和理解对象之间的关系.更易读的代码.更容易进行单元测试.但是,您还需要做很多选择和工作:


OR/Mapping
- 从关系模型获取数据到对象.OR映射器并不复杂,并且能够很好地处理它.但它增加了开发时间.


合同映射
- 将数据从服务器端对象映射到合同对象(通常是DTO)通常是一种很好的做法.由于这是一个非常适合CRUD风格架构的应用程序,因此DTO并没有真正为图片增加太多价值,只是映射工作.


共享代码
- 您可以使用共享代码方案,其中包含域数据和逻辑的程序集在客户端和服务器端都可用.这是紧密耦合,但当你有一个自然紧密耦合的客户端 - 服务器应用程序时,它并不一定是坏的.


无论您选择是否添加合同层,您都必须通过线路发送大型对象结构因为我们控制客户端和服务器,所以传输和编码应该是TCP上的二进制编码.那会有所帮助.使用数据集,您可以选择仅发送更改.前后发送整个对象结构可能是性能问题.发送整个对象结构的选项是以某种方式识别所涉及的更改(创建,更新,删除),并仅发送有关该更改的信息.理论上,将聚合根ID发送到服务器以及更改并不太难,要求服务器延迟加载聚合根,执行所做的更改,然后再次保存.但涉及的最大复杂性是确定所做的改变.你有没有采用这种方法？为什么？你究竟是怎么做到的？

演示文稿
确切的UI技术对于这个问题并不是那么重要,WinForms,Silverlight或WPF是可能的.让我们假设我们正在使用WPF,因为它是一个新的智能客户端.这意味着我们有两种方式绑定,可以正确使用MVVM.

绑定到用户界面的对象需要实现INotifyPropertyChanged并在每次更新属性时引发事件.你是如何解决这个问题的？如果您选择共享代码方案,则可以将其添加到域对象中,但这将涉及在服务器端添加从未在那里使用的代码和逻辑.如果你去合同对象,分离是更自然的,但是添加一层映射并不是很多增值.

技术
有一些技术可以帮助解决一些问题,但这通常会使其他问题复杂化.你是使用它们,还是自己从头开始构建东西？
**
- CSLA是可能的,但它使单元测试更加困难,并且似乎为数据访问增加了更紧密的耦合.它确实对许多问题有所帮助,但我个人对这项技术没有任何能力,所以它是否适合它是有点难以说的.
- WCF RIA服务可用于Silverlight解决方案,但肯定存在限制.数据大小是一个.
- WCF数据服务是另一种快速获取内容的方法,但REST没有太大帮助,而且您还缺乏RIA服务中的验证支持.

总结
如果你已经走到这一步,我希望你能够了解我的目标.我试图将其缩小以避免一次性讨论所有内容,但分布式开发很复杂,因此您必须考虑许多部分.

更新

谢谢你们的回应!我试图提出足够开放的问题以获得不同的答案,但具体到足以处理一些不常见的要求.

有不同的考虑因素有不同的优点和缺点,并且因系统而异.每种方法通常都会增加寻找解决方案的复杂性.这个问题的一个要点是特别提出一些额外的要求,而这些要求并不是直接适合今天通常是正确的答案 - 基于任务的UI.如果你愿意,我不是一个"CRUD-guy".但是由于各种原因(通常是遗留的),一些系统非常适合CRUD.

许多商业应用程序都有类似的需求,可以引导不同的方

业务相关
- 查看:向用户显示数据并更新相同的数据(读取和CUD - 创建,更新,删除)
- 验证:业务规则

UI相关
- 验证:UI规则
- UI更新:特定于仅使UI更新对象更改的代码(INotifyPropertyChanged)

网络相关
- 数据大小:通过网络发送的数据量

DB相关
- 延迟加载

SRP /重用相关
- 映射:由多层对象/分离问题引起

维护/更改相关
- …

我过去曾听过不同人的术语Data Driven和 Event Driven模型。我曾经用过google，但是这些术语对我来说仍然很模糊，因为它们看起来都和我相似

数据驱动编程是一种编程模型，其中数据本身控制程序的流程（而不是程序逻辑），在事件驱动编程的情况下，它是事件而不是数据本身控制程序的流程。

每个地雷的理解事件也是数据。例如，在基于员工的Web应用程序中-如果用户单击“创建员工”按钮，则这里的事件是创建员工（也仅是一种数据），而数据是与员工相关的信息。

现在，首先在服务器上将是事件，它将决定程序的流程，然后数据（与员工相关的信息）也将控制执行流程，例如是否将执行永久雇员不同的方法以及是否将临时雇员不同的方法

那么，不是每件事都是数据驱动的体系结构吗？如果没有，它们之间有什么区别？任何基于网络的示例都将有所帮助

Workbook aWorkBook = Workbook.getWorkbook(new File("C:\\Users\\Response.xls"));     
WritableWorkbook workbook1 = Workbook.createWorkbook(new File("C:\\Users\\Responses.xls"), aWorkBook);

我正在 SOAP UI 中使用 Groovy 脚本进行数据驱动测试。以上是创建新文件然后将 PASS 或 FAIL 结果写入该 excel 的代码部分。假设如果有 5 个测试用例，那么我只想在第一个循环（第一个测试用例）中创建一次新文件，然后在下一个循环中它应该打开现有文件。但目前它正在每个循环中创建新文件并覆盖数据和 PASS 结果仅显示最后一个测试用例。任何人都可以帮助解决这个问题吗？