Code First - I feel I am missing the point

Question

So to put things into perspective:

Until now i've had some experience with working with Entity Framework edmx models. The process (layer wise) would summarize to:

• creating the database, having a layer of objects generated in the edmx file
• having a layer of business objects (i am not sure if business is the right word) that are initialized from the edmx objects (and only the business objects are used inside my application)
• in the MVC site having a layer of view model objects wherever needed (whenever generating views directly from my business objects would not work)

I am under the impression that with Code First the database layer objects (previously named edmx objects) and the business layer objects are one and the same, practically skipping a layer. That is what a colleague who had much more experience than me told me.

The problem is that i don't think this is quite applicable. Limitations of code first like scalar keys, having navigational properties inside objects, being unable to map private fields inside the DB without workarounds and being forced somewhat to have autoproperties everywhere feel that i am messing up my business objects.

Quick Example: I have the entities of:

• Team : TeamId and Description (Backend, FrontEnd etc)
• Group : GroupId and Description (Developers, TeamLeaders, PMs, etc)
• Status: an object that has a Team and a Group, something that is not to be kept inside the DB
• User: UserId, FirstName, LastName
• Employee: a user which also is part of a Team and a Group (inside it has a User property and a Status property)

The Users table will be denormalized in the sense that it will be containing all the info my User class has, but also have a TeamId and a GroupId, which will be populated only if the User is also an Employee. So basically Employee and User are mapping to the same table

This leads to some weird workarounds, since for instance in the Employee class i need to expose UserId as a primary key, and not get it through the User property's UserId (because the key needs to be scalar) which is ugly; also, even though i have a Status property inside the Employee class, i still need to have 2 additional properties (TeamId and GroupId, gotten from the Status properties Team and Group) in order to have scalar foreign keys to Groups and Teams, which again is cumbersome and feels messy. Adding inside the Group/Team class a virtual IList for navigational purposes also seems unneeded (though from what i've seen this can be skipped). Also having only auto properties for the objects seems wrong, i want to have privates instantiated by the ctor and only getters for them.

Am I not getting it ? Do i still need the additional layer even while using code first ? Is my model messed up from the beginning ? Sorry i cannot provide you with the code, but i am not home at the moment, and the code block seems very dodgy to use :D

Answer 1

I tend to work within the repository and service pattern(s). In my expereince, I have always found it easier to solidify what my application is going to be using (models) and how they will stored (structure). I lean on the side of building up the database with all the linking and FKs, building an EF model (EDMX), and then adding a layer on top of that as a Service/Repo layer. This way, your application always just references that Service/Repo layer, and if your EDMX breaks or you have to change the way something is calling your EDMX, you only have to fix it in one spot. Recently I have been doing a mix of the IRepository pattern mixed in with a Service class, and it seems to be meshing really well and is easy to use. Hope this clarified some for you, best of luck!