13

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!

CRABOLO
  • 8,605
  • 39
  • 41
  • 68
s0ftimage
  • 175
  • 8
  • What will the application do with the data the it gets from the plugins? I assume it's some predefined action, so coding against an interface (one that the app and plugin know about - maybe in a seperate `Commons` library) would make sense. – Omar May 04 '11 at 04:54
  • Thanks Omar. I would like the main application to save the result generated by the plug-in to a database; I guess I can do it on the [Return]. Thinking more about my question, what I really want to know is what is the best practice for marshalling data across libraries. I ended up creating a new POCO (without getters and setters) with just the fields I was going to use, adding them to a List, disposing the EF context, and returning the list. – s0ftimage May 04 '11 at 16:44
  • Your approach makes sense to me, although I would have probably used a new POCO (or list of POCO) to send data to the plugin as well. No need for the plug-ins to really know anything about your data layer, right? – Adventure May 04 '11 at 19:11
  • just FYI - my plug-ins needed complex data from three different tables. My data originates from a database, through Entity Framework, and I dont have that much experience with its object. I am researching passing XML (as a string) to the plugins. Each plugin can parse the XML to get the values it needs. The plugins also return data as a string(with XML). I guess its just lack of understanding of the gazillion options available to pass data back and forth. – s0ftimage May 11 '11 at 17:37

1 Answers1

1

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 :)

Jeff
  • 13,943
  • 11
  • 55
  • 103