Thanks! (and a usage note)

Oct 23, 2014 at 1:04 PM
This project alone justified updating to EF 6.1.1! What a simplification of the process of dealing with TVFs and SPs!

I'll also point out that the base class, FunctionConvention, proved to be more useful to me that the generic FunctionConvention<T>. In my work, I create DbContexts at runtime using DbModelBuilder (under the covers) directly and discovering the CodeFirst configuration by reflection. I amended this process to reflectively discover FunctionConventions and inject them into the dynamically created model. Because the actual DbContext is not known at compile time, the FunctionConvention specializations I created do not use a DbContext as the second constructor argument; instead they use another class containing the DbFunctions and a DbContext as a constructor parameter. The appropriate DbContext is injected by my repository code a runtime. This allows me to package the DbFunctions separately from the DbContext that ultimately consumes them, allowing for reuse where necessary and practical.
Coordinator
Oct 25, 2014 at 2:57 AM
Hello DrDave,

Thanks for sharing your scenario. It is really interesting (and not something I actually thought of). Adding the non-generic FunctionConvention was a contribution from Angel Yordanov. I am glad you find this project useful.

Thanks,
Pawel
Nov 26, 2014 at 9:07 AM
My latest CodeProject article (http://www.codeproject.com/Articles/845371/Polymorphic-ObjectResult-lt-T-gt-for-Entity-Framew) shows my usage pattern in downloadable code. It also illustrates the problem on which I was working when I discovered your work. Thanks again.

BTW: The end of the article suggests that adding BindFlags.NonPublic to the method probe in FunctionDiscovery.FindFunction would make a reuse packaging improvement.
Coordinator
Nov 30, 2014 at 5:24 AM
Hello DrDave,

Your codeproject article is very interesting! I created a work item to also discover non-public methods.

Thanks,
Pawel