A few days ago I went to start a new project using Entity Framework. Like every other relational database in the world, I knew I would need some “lookup value” style tables. Y’know, WidgetStatus, FrobbleType, that sort of thing. EF had never had a good mechanism for quickly defining and referencing these types of lookup tables, but now there is Enum support! I thought this would be perfect, but it turned out to be woefully inadequate. So, I realized that EF still needed a good answer to creating lookup tables. I did some searching, and couldn’t find any good solutions, so I wrote one.
I started working for a new company a few weeks ago, and I have been spending a lot of time just getting used to the new portfolio and all of the new techniques and conventions in use there.
One of the things I wasn’t used to is the heavy use of stored procedures that act as custom getter methods within the DAL layer of the .NET applications. The DAL is code generated and the codegen templates automatically know to transform those sprocs into getters on the generated entity manager. So if I have a Customer table, and a sproc in the database called sp_Customer_SearchByName, the codegen process will automatically create a Customer entity, along with a CustomerManager that has a SearchByName method on it, which takes the same inputs as the sproc and returns a collection of Customers.
One of the things I’m looking at is whether Entity Framework makes sense for this portfolio, and I wasn’t sure how EF would handle this type of situation. After pleading ignorance, I was told the magic keyword that I needed: Function Imports!