问题标签 [data-driven]

我想创建从我的 MS SQL 服务器加载的 ASP.NET 4.0 动态页面。基本上，它是一个包含信息的位置列表。例如：

我什至不知道从哪里开始，也许是 URL 重写？

在哪里可以找到有关我的订阅错误的更多详细信息。

我有一个数据驱动的订阅，显示状态：

完成：总共 24 个已处理 24 个；24 个错误。

但我的跟踪文件 ReportServerService__xxxxx.log 没有显示任何错误。它确实显示订阅已运行，但没有错误。

我的服务器 DefaultTraceSwitch 设置为 3，也尝试了 4

我了解 2005 年使用的其他日志文件已合并到 ReportServerService__xxxxx.log 文件中。

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


这个问题有很多细节，为此道歉，但这是因为我想为答案设置适当的上下文。


其他一些假设
- 在 Microsoft 世界中并不少见，大多数以前的应用程序都是使用 DataSet 编写的，因此它是所涉及的开发人员最知名的技术。但是，假设开发人员也精通 OO 思维。
- 您需要在客户端和服务器上运行验证。
- 您不会以表格形式显示大多数数据。
- 这不是一个内网应用程序，所以你不能对带宽假设太多


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

如果你选择数据集，你会有一些积极和消极
的方面 - 就积极方面而言：在从数据库中获取数据、通过网络获取数据以及通过网络返回更改的数据方面，你会获得一些 Microsoft 支持更小的块——因为你可以指定只发送更改。发送较少的数据是好的，因为可能涉及相当多的数据。
- 缺点是：在验证、业务逻辑等方面，你得到了一种程序形式的代码，而你没有得到面向对象代码的好处——行为和数据结合在一起，一种更自然的工作方式和思考方式你在做什么，并且可能与验证逻辑有更密切的联系。您也可以忽略将数据集放在网格中的好处，因为这不是常见的用例。

如果您选择对象，这是相同的练习，但涉及更多选项：
积极因素：行为和数据一起。验证逻辑更接近。更容易看到和理解对象之间的关系。更具可读性的代码。更容易进行单元测试。但是您还需要做很多选择和工作：


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


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


共享代码
- 您可以使用共享代码场景，其中包含域数据和逻辑的程序集在客户端和服务器端都可用。这是紧耦合，但当您拥有一个自然紧耦合的客户端-服务器应用程序时，它不一定是坏事。


无论您是否选择添加合同层，您都有必须通过网络发送的大型对象结构由于我们同时控制客户端和服务器，因此传输和编码应该是 TCP 上的二进制编码。这会有所帮助。使用数据集，您可以选择仅将更改发回。来回发送整个对象结构可能是一个性能问题。发送整个对象结构的一个选项是以某种方式识别所涉及的更改（创建、更新、删除），并仅发送有关这些的信息。理论上，将聚合根 ID 以及更改发送到服务器并不难，要求服务器延迟加载聚合根，执行所做的更改，然后再次保存。但所涉及的巨大复杂性是确定所做的更改。你有没有选择过这种方法？为什么？你具体是怎么做的？

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

用户界面中绑定的对象将需要实现 INotifyPropertyChanged 并在每次更新属性时引发一个事件。你如何解决这个问题？如果您选择共享代码场景，您可以将其添加到域对象中，但这将涉及在服务器端添加代码和逻辑，而这些代码和逻辑永远不会在那里使用。如果您使用合约对象，这种分离会更自然，但这并没有增加一层映射的价值。

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

总结
如果您已经走到了这一步，我希望您对我的目标有所了解。我试图缩小范围以避免一次讨论所有内容，但是分布式开发很复杂，因此您必须考虑很多部分。

更新

谢谢你们的回应！我试图问的问题足够开放，可以得到不同的答案，但又足够具体，可以处理一些不常见的要求。

有不同的考虑，有不同的优点和缺点，并且因系统而异。每个通常都会增加寻找解决方案的复杂性。这个问题的要点之一是获得一些额外要求的答案，这些要求不一定直接适合今天通常是正确的答案 - 使用基于任务的 UI。如果你愿意的话，我不是“CRUD 人”。但是由于各种原因（通常是遗留系统），一些系统非常适合 CRUD。

许多商业应用程序都有类似的需求，这些需求朝着不同的方向发展：

业务相关
- 查看：向用户显示数据并更新相同的数据（读取和 CUD - 创建、更新、删除）
- 验证：业务规则

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

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

数据库相关
- 延迟加载

SRP/重用相关
- 映射：由多层对象/分离关注点引起

维护/更改相关
- 更改：添加新信息（列/字段）
- 代码量
- 重用和“更改原因”

技术限制
- 变更跟踪

但这些只是一些非常具体的。您总是需要知道您认为哪些“-ilities”最重要，因此您需要什么程度的可伸缩性、可用性、可扩展性、互操作性、可用性、可维护性和可测试性。

如果我想对大多数情况进行概括，我会说：

客户端
- 使用 MVVM 进行分离和可测试性
- 在 DTO 之上创建 VM - 在 VM 中
实施 INotifyPropertyChanged。
- 使用 XamlPowerToys、Postsharp 或其他一些帮助解决此问题的方法是值得
的 - 在 UI 中分离读取和 CUD
- 使 CUD 基于任务，并使用命令或类似的命令将这些操作发送到服务器端

服务器
- 为每个屏幕定制一个 dto - 或者使用 Ayende 在http://msdn.microsoft.com/en-us/magazine/ff796225.aspx
中描述的多查询方法 - 使用自动映射来避免繁琐的手动和与您尝试解决的问题步骤完全无关，该映射是 - 让域模型主要关注业务操作，包括与 CUD 相关的操作，而不是读取 - 避免可重用性增加更改原因的数量 -避免封装问题 - （并由此启用 CQRS 样式架构，并可能及时分离读取和 CUD 的缩放） - 尝试找到一种非常适合应该做什么的验证方法（好读：





http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/02/15/validation-in-a-ddd-world.aspx）

这是我在这种特殊情况下会采取的方法吗？

好吧，这就是我想开始讨论的内容:) 但似乎比我希望的要难（除了你们两个）。

假设我有一些我想要几种数据。我认为最简单的例子可能是游戏中的瓷砖：我会有草、石头、树等，每个都有不同的值集。

我会立即继续制作一个文件并在运行时将其读入，因此我不必重新编译它以使用 C++ 之类的东西进行调整。但是，如果我使用的是 Python 或其他一些解释性语言，那么必须将文件制作成如下格式是否有意义：

种草
颜色 0xdfdfdf
走真
看真

而不是：

类草（瓷砖）：
定义 初始化（自我）：
我不记得如何初始化。父母
self.colour = 0xdfdfdf

当你不编译时，第一个明显的好处就消失了。

我听说过最小化代码和最大化数据的概念，并且想知道其他人可以给我什么建议，告诉我在构建自己的系统时应该如何/为什么要这样做？

我正在开发 PHP / MySQL 中的数据驱动菜单系统。我不知道如何删除菜单项而不让其中一些成为孤立项。

所有顶级菜单项都有一个零 (0) 父 ID 值，表明它们是顶级的。我的 gridview 显示所有菜单、顶级和子菜单项，它允许多选删除。

问题是，如果在 gridview 中选择的要删除的项目之一是顶级菜单项，则其下的所有子菜单都将成为孤立的。

我需要实现的一般逻辑是什么？

问题

数据库 ID “毫无意义”是一个好的经验法则吗？相反，以一种一眼就能认出的方式构建 ID 是否有显着的好处？优缺点都有什么？

背景

我刚刚与我的同事就我们数据库中 ID 的一致性进行了辩论。我们有一个利用 Spring 的数据驱动应用程序，因此我们很少需要更改代码。这意味着，如果出现问题，数据更改通常是解决方案。

我的论点是，通过使 ID 保持一致和可读，我们可以为自己节省大量时间和长期的麻烦。一旦设置了 ID，它们就不必经常更改，如果操作正确，未来的更改将不会很困难。我同事的立场是，ID 永远不重要。将信息编码到 ID 中违反了数据库设计策略，并且保持它们有序需要额外的工作，“我们没有时间去做”。我在网上找不到任何支持这两种立场的东西。所以我要求助于 SA 的所有大师！

例子

想象一下这个表示杂货店食物的简化数据库记录列表，第一组表示在 ID 中编码的具有含义的数据，而第二组则没有：

ID的含义：

ID没有意义：

概括

What are the pros and cons of keeping IDs readable and consistent? Which approach do you generally prefer and why? Is there an accepted industry best-practice?

-------- edit ( helpful background info from comments, below ): --------

In our tables, the Primary Key is always an ID field containing a unique integer. At first, that integer was arbitrary. Over time, some of these IDs naturally took on meaning among developers/testers. During a recent refactor, certain developers also took time to make all IDs easier to recognize. It made everyone's job 100X easier. Some people (who don't actually use the data/code) vehemently disagreed for theoretical reasons. In practice, not one of those objections are holding true. Moreover, all developers using the data agree that it's now significantly easier to maintain.

I'm looking for (but haven't seen) a defensible argument against using immediately recognizable IDs in a data-centric environment.

我有一个数据驱动的单元测试，它使用 CSV 文件作为其数据源。我文件中的一列被视为字符串。在我添加一行可以将该列的值解释为日期之前，它工作正常。当我这样做时，前面几行的测试开始失败。似乎在列中有一个“日期”使其将列中的所有值都视为日期。不能被解析为日期的值会被赋予一个 DBNull 值。有没有办法防止这种情况发生？也许通过指定我的数据源中的每一列应该被视为什么类型？

我想知道以前是否做过这样的事情：

我最近开始使用 C 语言开发一个网络库。该库维护一组套接字，每个套接字都与两个 FIFO 字节流、输入和输出相关联。

使用该库的开发人员需要注册一些回调，包括识别器函数和处理函数。如果新数据到达套接字（即输入流），则调用每个识别器。如果其中一个识别器找到数据的匹配部分，则调用其关联的处理程序，使用数据并可能在套接字的输出流上排队新数据，计划稍后传输。

这里有一个例子来说明这个库是如何使用的：

对我来说，这是用 C 编写通用网络库的最明显的方法。我使用 Google 做了一些研究，但我找不到用 C 编写的类似内容。但很难相信我是第一个实现这种方法的。

是否还有其他像这样的数据驱动的通用 C 网络库？
你会使用它们吗？

我正在尝试设置对 SSRS 报告的数据驱动订阅。我想使用一个共享点列表，其中包含收件人电子邮件地址和一个报告参数，该参数将为每个收件人以不同的方式过滤报告的内容。

Microsoft SharePoint 列表是创建数据驱动订阅向导 (SSRS 2008 R2) 中的选项之一，但我在互联网上找到的教程都没有描述如何配置连接字符串和制定查询以返回列表的内容. 我在创建的数据驱动订阅中可以找到的所有内容都使用与 Sql Server 数据库的连接来驱动交付和配置。我宁愿使用共享点列表，因为这似乎是一种管理收件人的简单方法。

有人做过这个或者有一个很好的链接到如何配置这个设置的例子？