Lightswitch:运行时的动态数据绑定

老实说，我认为你在要求一些实际上无法完成的事情。

我相信有一些技术可以促进您所追求的那种动态绑定的数据模型（我在Visual Basic 6.0中看到过类似的内容，但一旦数据集开始扩展，该解决方案就会遇到数据访问性能问题）。LightSwitch和VB6.0之间的区别在于，VB6.0允许您在运行时动态构建屏幕并修改数据绑定，而VB6.0应用程序是后期绑定的，这一点更为方便。它们继承了作为运行时解释器运行的pre.net VB。LightSwitch的输出是编译.Net MSIL的，尤其是在服务器端。尽管该代码只编译到MSIL，而不是汇编语言或机器代码，但它是强类型的和早期绑定的。

LightSwitch在编译时针对服务层执行数据绑定，方法是生成基于T4模板的代码，这些代码针对各自.LSML文件中的数据和屏幕模型运行，并根据需要使用附加的JavaScript代码扩展基类。除非您正在动态生成服务，否则我看不出LightSwitch如何将屏幕（在这种情况下很容易）绑定到运行应用程序时不存在的服务。

您还应该注意，LightSwitch通常希望数据模型中的实体是强类型的。即使您能够创建一个服务，将键值对（即字典对象）实体转换为看起来像为CRUD操作公开的强类型表格数据集，数据访问的性能也会非常糟糕，而且如果没有一个为仲裁外键、唯一约束、表联接、，等等…ugh我看不出它的性能有关系数据库那么高。某种NoSQL数据库可能会提高性能，但您需要一种服务，将LightSwitch LINQ to Entities查询转换为特定于平台的map reduce操作。

我并不是说你的要求不能以任何绝对的方式实现。如果您将屏幕数据组成XML文档，这些文档可以写入SQL Server表中的XML类型列中，那么这可能是可行的。为了实现这一点，您可能需要包含某种引用XML模式文档（或者针对XML类型中包含此类引用XSD的表的外键），以便能够根据需要打开屏幕文档。

然而，我不认为Silverlight是基于这些XSD构建屏幕的最佳技术，也不认为它是将数据存储层与暴露这种以XML为中心的数据模型的服务进行数据绑定的最佳技术。您甚至可以将此过程烘焙到屏幕模板中，但最终Silverlight的类型太强，并且针对早期绑定进行了优化。HTML客户端将更有意义，因为您可以在为屏幕发出HTML时拦截create（）事件，并在before_ApplyChanges（）屏幕事件中将屏幕数据序列化为XML以通过有线传输。然而，您所要做的将有效地替换LightSwitch发出的几乎所有内容，除了CSS。

在我看来，你最好使用ASP.NET MVC应用程序来完成这项工作，因为你可以围绕KVP模式构建模型，构建视图模板，有效地将XSLT转换应用于你的XML模式/数据，以完成你需要的繁重工作，并且在生成的屏幕和动态数据模型之间不会有额外的代码层（即LightSwitch的管道）。Dynamic（screen）to Dynamic（data）比看起来更像Dynamic（screene）to Strongly Typed（Silverlight屏幕管道）甚至更像more Strongly Type d（实体服务模型）to Dynamically Typed（XML存储）的解决方案要简单得多，效率也更高。

请记住，强类型存在是有原因的。它表现良好。它会得到结果。如果您有一套明确的业务需求，而这些需求只能通过动态表单和数据来提供，那么可以考虑使用针对该模式进行优化的解决方案体系结构。IMO，LightSwitch（请记住，早期绑定使用生成的代码）不是您想要的架构挥手，施加绝地精神控制：）