Hopefully just a quick question. I'm working on a library that needs to handle object to SqlDB interactions (insert, update records primarily). The DB that I'm going to be working against has really no normalization, and that wont change any time soon. So what exists is several tables of identical schema's underneath one DB. I have a process for handling this, but, was hoping to incorporate EF for the sake of ease of management. My question is, I will not know ahead of time the table names under said database, so for server1, tables could be:
table1,table2,table3,table5.
server2 could only have table99
and so on and so forth. Once again, each table contains identical column layouts, same data types, etc. They're redundant to store slightly differing types of data (I have no control over this part).
Would a code first approach be suitable for this (I've not used EF very much up to this point) given what I've described thus far? I've attempted so far to create a base entity through the designer, and use it to connect to different tables as needed (I'll only ever need to connect to one at a timel), but haven't been able to do so successfully yet.
Thank you ahead of time for any insights provided.
UPDATE:
This may not work after all. I was writing test code, and noticed that I can't reference the DbContext object. I'm locked into .Net 3.5 with this project, and am assuming this is the reason. Like I said, I'm pretty new to EF, so if anyone knows something obvious that I'm missing, please don't hesitate to set me straight. Otherwise I'll move in a different direction.
Thanks again.
JP