Question

I have a project with an existing database which was initially created for a legacy application. It works fine, but over time quite a few of the tables / fields have been lost or under-utilized, but the historical data MAY be useful someday so they’re not going anywhere.

Enter 2012 (’13) and Entity Framework 5, an ORM with built in POCO generation (Nice Add!). So bang.. Get a connection to the Oracle Database, gen. up a context and some POCO’s.. suh-weet!! But wait.. my POCO’s arent really the POCO’s I would like to deal with… There’s a bunch of fields which i dont need anymore (not to say I’ll NEVER need them, but i can’t know for sure), so now i’ve got these POCO’s which are basically bloated table mappers… So what should I do.

I see a few solutions here..

1). I could throw them around and only use the fields that I need.

2). I could get into the Model Surface and start axing the unused fields.

3). “Code-First” approach and tie the objects into the existing DB, it’s a large DB though (i’m pretty sure this is possible, right?)

4). Create my own POCO / DTO’s in it’s own model project and these will essentially become my “domain model”, but the mapping back into the context could be painful..

Lastly, do these POCO’s / DTO’s need to be in their own project?? What is there REALLY to gain.. seeing things like “YAGNI”, i feel like it can sit right under the .edmx and never bother anyone..

On a side note, i will be needing a few of these via JSON too, so the whole serializable ability needs to be considered..

Can i just partial class the generated POCO’s and only “Attribute” the properties I’ll be needing?

anyhow, it’d be great to hear from past experience, or thoughts on the matter..

I could see this being in Programmers, but i figured I’d start it here.

Answer 1

We have a very similar situation, a large legacy DB2 database of which we need small portions of specific tables for our applications.

To do this we used entity framework code first models for the relevant subsections of data we were interested in. This meant we could do a few important things:

• remove irrelevant data from the model to make code more discoverable
• rename fields inside our model and map them to names that make sense in the app rather than existing column names
• reduce the volume of data pulled back by queries (ie our selects dont grab all the extra bits)
• where 2 formats of data exist use the modern standard rather than historical format

This works out really well for us, however a couple of things to note:

• if you are writing make sure you include all required fields in the model
• you can generate you CF classes but you will have to trim them a bit
• generating from non mssql can sometimes be more tricky

In terms of json serialisation we do this too however we use a different model for this and use automapper to translate. You should in most cases be able to serialise without needing to add extra attributes but if they are required you can just add them to your pocos alongside any ef attributes.