如何动态生成 Business Connectivity Services
我们正在尝试部署业务连接服务 (BCS) 模型解决方案，其中模型中的属性取决于 Web 服务公开的数据的结构。
理想情况下，BCS 模型将公开键/值对的集合，然后将其转换为共享点列表中的列，因为这意味着相同的模型可以用于多个不同的数据集，但是从我们所知，这并不是如何实现的。 BCS 模型的设计是因为它们依赖于强类型的模型来反映正在导入的实体。
因此，就目前情况而言，我们正在寻找一种解决方案，该解决方案使用户能够通过 sharepoint 中央管理中的自定义页面提供远程数据集的 url 来“创建”新的外部列表，然后该解决方案将自动构建 BCS 模型项目（通过更改项目模板），然后动态编译并发布生成的功能。
通过这种方式，我们可以创建“固定”类，其属性表示正在导入的数据的结构。
例如，数据源 A 可以公开，
<cars>
<car>
<color>blue</color>
<make>ford</make>
</car>
<car>
<color>red</color>
<make>lotus</make>
</car>
</cars>
在这种情况下我们需要“汽车”的 BCS 模型，它有两个公共属性：颜色和品牌 但是数据源 B 可能会公开，
<invoices>
<invoice>
<amount>£34.00</amount>
</invoice>
<invoice>
<amount>£34.00</amount>
</invoice>
</invoices>
在这种情况下我们需要一个带有单个公共属性的 BCS 模型“发票”来表示金额。
感谢任何人对这种方法或实现这一目标的“最佳实践”方式的反馈。
We are trying to deploy a Business Connectivity Services(BCS) Model solution where the properties in the model depend on the structure of the data exposed by a web service.
Ideally the BCS Model would expose a collection of key/value pairs which are then converted to columns in a sharepoint list later as this would mean that the same model could be used for several different datasets, however from what we can tell this is not how BCS Models have been designed, as they rely on the model to be strongly typed in order to reflect the entity being imported.
As it stands we are therefore looking at a solution which enables the user to "create" a new external list by providing the url to a remote dataset through a custom page in sharepoint central admin, that will then automatically construct the BCS Model project (by altering a project template) and then compiling and releasing the resulting feature on the fly.
This way we can create the "fixed" class with properties that represent the structure of the data being imported.
for example, datasource A could expose
<cars>
<car>
<color>blue</color>
<make>ford</make>
</car>
<car>
<color>red</color>
<make>lotus</make>
</car>
</cars>
in which case we need a BCS Model for "car" which has two public properties , color and make
however datasource B could expose
<invoices>
<invoice>
<amount>£34.00</amount>
</invoice>
<invoice>
<amount>£34.00</amount>
</invoice>
</invoices>
in which case we need a BCS Model "invoice" with a single public property for amount.
Would appreciate anyones feedback on this approach or the 'best practice' way of achieving this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
[我有在 .Net 中做过类似事情的经验 - 我不确定这对你有多大相关性。]
我必须编写一个可以处理任何文件格式的导入工具。为了正确处理这个问题，我编写了一个小类，它将采用 xml 格式定义（名称、数据类型、格式字符串、自定义解析器等）并生成一个可以读取文件并公开 IQueryable
IQueryable< 的类。 FileFormat>和一些附加元数据。值得注意的是，为了使其完全灵活，我必须允许格式定义提供将被编译和执行的 C#/VB lambda（例如，当输入日期格式是非标准并且需要自定义解析器时）。这显然是一个安全风险 - 因此，当我实例化动态类时，我是在一个单独的 AppDomain 中进行的，权限很少。这可能不适用于您的情况。
我们使用自定义模板引擎生成代码，然后使用 System.Codedom.Compiler 命名空间 - 这允许我们创建程序集并缓存它们，直到定义更改。如果您做类似的事情，可能值得考虑 Razor 模板引擎。
我们遇到的唯一真正问题是针对未知数据类型进行编码。通过使自定义类实现我们自己的 IImportFile 接口，该接口以标准方式公开元数据（实际上与 xml 规范中的信息相同），我们可以轻松解决它。
我们很幸运，因为这是一个供受信任用户使用的工具（至少只有受信任的用户才能提供新的文件格式规范），因此安全风险是有限的。如果您根据用户输入编译代码，请确保您已采取足够的保护措施。
[I've had experience doing something similar in .Net - I'm not sure how relevant this will be to you.]
I had to write an import tool that could handle any file format. To handle this properly, I wrote a small class which would take an xml format definition (name, data type, format string, custom parser, etc..) and generate a class which could read the file and expose an
IQueryable<FileFormat>and some additional metadata.It's worth noting that to make it completely flexible, I had to allow the format definition to provide a C#/VB lambda which would be compiled and executed (eg, when the input date format was non-standard and needed a custom parser). This is clearly a security risk - so when I instantiated the dynamic class, I did so in a seperate AppDomain with very few privilieges. This may not apply in your situation.
We used a custom templating engine to generate the code which was then compiled using the System.Codedom.Compiler namespace - This allowed us to create assemblies and cache them until the definition changed. It may be worth considering the Razor templating engine if you do something similar.
The only real issues we had arose from coding against an unknown data type. By making the custom class implement our own
IImportFileinterface which exposed metadata in a standard way (effectively the same info as in the xml spec), we could work around it without too much effort.We were lucky in that this is a tool for trusted users (at least only trusted users can provide a new file format specification) so the security risks were limited. If you're compiling code based on user input, make sure you've got adequate safeguards in place.