将数据编入/编出插件的最佳方法是什么？
我正在使用 MEF 和 EntityFramework 4 构建我的工作站代理应用程序。
该应用程序是一个简单的代理，在具有插件架构（以及许多 .dll 文件形式的插件）的计算机上运行。
每个插件都会查询自己的插件特定表。主程序（或代理）需要将信息传递给插件，并从插件接收信息。
插件将使用实体框架 4.1 来检索数据，因此它已经将数据格式化为对象（可能是重对象，因为它们与 EF 上下文绑定）。另外，我从数据库中提取的数据是一系列联接，因此数据与我已经创建的任何 POCO 身份/类都不匹配。
将数据编入/编出插件的最佳方法是什么？考虑到我正在使用 MEF 将各个部分连接在一起，并且我已经在插件中拥有了数据对象。我应该创建一个新的 POCO 并将实体数据移入其中，然后对数组进行洗牌吗？我应该创建一个列表吗？我不仅对可以做什么感兴趣，而且对最佳实践感兴趣！
I am building my workstation Agent application using MEF and EntityFramework 4.
The application is a simple agent that runs on a computer with a plug-in architecture (and many plugins in the form of .dll files).
Each plug-in will query their own plugin-specific table. The master program (or agent) needs to pass information to the plug-in, and receive information from the plug-in.
The plug-ins will use the Entity Framework 4.1 to retrieve the data, so it will already have the data formatted as objects (perhaps heavy objects since they are tied to the EF context). Also, the data I am pulling back from the database is a series of joins, so the data doesn't match any of the POCO identities/classes I had already created.
What is the best way to marshall data in/out of the plug-ins? Taking into consideration that I am using MEF to tie the pieces together, and that I already have objects for the data in the plug-ins. Should I create a new POCO and move the Entity Data into it, then shuffle arrays? Should I create a List? I am not only interested on what can be done, but what are best practices!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一篇关于数据传输对象的好文章。它涉及到您在 POCO 对象中提出的要点。由于您构建的应用程序具有进一步扩展和自定义的明确意图，因此我认为 POCO 对象是正确的选择。否则，任何其他组件都需要依赖 EF，这对于插件开发人员来说可能是一个负担。使用 POCO/DTO 对象，您将可以更好地控制发送的内容以及发送的结构。
插件应该实现（虚拟？）基类或接口。我可能会选择接口，因为对于插件开发人员来说，将接口添加到他们的代码中比基类更容易。
真的，我并不是在说任何你、奥马尔和冒险还没说过的新话。基本上我是说我认为你已经很好地掌握了它:)
This is a good article on Data Transfer Objects. It touches on the points you are bringing up here with the POCO objects. Since your building an application with the explicit intent of further expansion and customization, I think that the POCO objects are the way to go. Otherwise, any further components will require dependencies on EF which may be burdensome for the plugin developers. With the POCO/DTO objects, you will have a lot more control over what gets sent and what structures it gets sent in.
The plugins should either implement a (virtual?) base class or an interface. I would probably choose interface because - again - it will be easier for plugin developers to add an interface to their code than a base class.
Really, I'm not saying anything new that you, Omar and Adventure haven't already said. Basically I am saying that I think you've already got a good handle on it :)