1

Here's the issue: My database administrator wants to be able to add/remove database objects without requiring a reinstallation of the application, but I want to be able to use the rich data that entity framework provides on the data types returned from stored procedures.

Is there any possible way to rebuild, add, or remove entities from Entity Framework at runtime? For example, if the dbcontext is contained within an isolated AppDomain, is it possible to reload the AppDomain (e.g. after running EdmGen.exe at runtime) to add new entity types? If not, is there any way that I can swap out the datacontext with another one at runtime?

devinbost
  • 4,658
  • 2
  • 44
  • 57
  • 1
    Why is this different from adding new types at runtime without EF? – soandos May 20 '14 at 20:24
  • @soandos, do you have a better idea for how I might be able to autogenerate types from database objects in a way that allows me to see the type signatures of input parameters and result sets from SQL Server stored procedures (at runtime)? – devinbost May 20 '14 at 20:30
  • Perhaps I'm missing something. Are you looking for a way to store the type signatures of SQL stored procedures somewhere in your application without recompiling? Or are you trying to create a new type for the stored proc? – soandos May 20 '14 at 20:32
  • Both. I need to be able to reflect (e.g. via IL) on the stored procedure to determine the types returned as a consequence of its invocation. (Entity Framework generates a result type to represent the result set as a Complex Type.) I also need to be able to detect the stored procedure's input parameter names and types when given only the stored procedures's name. Perhaps I can solve the problem if I can do this via ILGenerator or expression trees without EF at all. – devinbost May 20 '14 at 20:41
  • As far as the first part is concerned, if all these types really are is just a bag of values, why not just use a `Tuple` with a tag entry (to prevent two types that are otherwise identical but are of different "logical types") to store the type? As far as the last part goes, I think thats just a map of some kind between names and signatures. Long story short, I think EF is not the issue here at all. Your problem is more basic. If you can do it with ILGenerator or expression trees, or tuples, then that is the way to go. – soandos May 20 '14 at 20:46
  • 1
    But what about the rest of the application? If the class model changes all the time, how can you build an application on top of it? Anyway, I don't think EF is your best choice here. It's really not suited to dynamic data models. Even the old datasets or ADO.Net do better jobs here. – Gert Arnold May 20 '14 at 20:53
  • Then how exactly do I obtain the names and types of values returned from a stored procedure when given its name (as a string)? – devinbost May 20 '14 at 20:57
  • @GertArnold, it's really quite simple. I am using IL to invoke the stored procedure, and based upon the types returned from it, I am able to determine the proper decisions to make. The stored procedures are used for very specific purposes, so it's not like the entire application is mutable. – devinbost May 20 '14 at 21:01
  • The only other ways that I am aware of use either sys.dm_exec_describe_first_result_set_for_object, which is only available in SQL Server 2012 and above, or an ugly hack involving a loopback. (See http://stackoverflow.com/questions/14574773/retrieve-column-names-and-types-of-a-stored-procedure .) sys.dm_exec_describe_first_result_set_for_object also does not provide information on the return types for procedures involving dynamic SQL. – devinbost May 20 '14 at 21:04
  • Maybe a micro ORM like Dapper fits the bill here. It will read the result of any stored procedure in dynamic data, so in C# code you can analyze the properties and values of the dynamic types. – Gert Arnold May 20 '14 at 21:07

0 Answers0