If we were to buy the materials to build a house, would we buy the bare minimum to get four walls up and a roof, without a kitchen or a bathroom? Or would we buy enough material to build the house with multiple bedrooms, a kitchen, and multiple bathrooms? The problem lies in how we define "bare minimum". The progression of software development has made us realize that there are ways of building software that do not require additional effort, but reap serious rewards. This is the same choice we are faced with when we decide the approach to take with Entity Framework. We could just get it running, and it would work most of the time.

Customizing and adding to it later would be difficult, but doable. There are few things that we would need to give up for this approach. The most important among those is control over how code is written. We have already seen that applications grow, mature, and have features added. The only thing that stays constant is the fact that at some point of time, we will come to push the envelope of almost any tool in some way that we leverage to help us. The other side is that we could go into development, being aware of the value added benefits that cost nothing, and with that knowledge, avoid dealing with unnecessary constraints.

When working with Entity Framework , there are many paths and options presented to us. We can approach the business problem by thinking of the database-first approach, modelling our domain-first approach, or by writing our POCOs (Plain Old CLR Objects) first. While modelling the domain-first approach, we are not concerned with the implementation of classes, but merely the structure of interactions. In contrast, in POCO or code first, we write the implementation as a way to communicate that design. All of these approaches will solve the problem with varying degrees of code and flexibility. When we are connecting to a database and working with data, there are a couple of areas where the code is almost the same. No matter what our implementation is, these pieces will not change much. However, it can affect their flexibility.

Starting with a database-first approach in Entity Framework means we have an existing database schema and are going to let the schema, along with metadata in the database, determine the structure of our business objects and domain model. The database-first approach is normally how most of us start out with Entity Framework, but the tendency is to move towards more flexible solutions as we gain proficiency with the framework. This will drastically reduce the amount of code that we need to write, but will also limit us to working within the structure of the generated code. Business objects, which are generated by default here, are not usable with WCF services and have database logic in them that makes them poor candidates for usage throughout the application. This is not necessarily a bad thing if we have a well-built database schema and a domain model that contains simple structures which will translate well into objects. Such a domain and database combination is a rare exception in the world of code production. Due to the lack of flexibility and the restrictions on the way these objects are used, this solution is viewed as a short-term or small-project solution.

Modelling the domain first allows us to fully visualize the structure of the data in the application, and work in a more object-oriented manner while developing our application. This lends itself to the architect and solution lead developers as a way to define and control the schema which will be used. However, this approach is rarely used due to a lack of adoption, and that it has the same constraints as the generated database-first approach. The main reasons for the lack of adoption have been the lack of support for round trip updates, and the lack of documentation on manipulating the model as to produce the proper database structure. The database is created each time from the data model causing data loss when structural changes are made.

Coding the objects first allows us to work entirely in an object-oriented direction, and not worry about the structuring of the database, without the restrictions that the model-first designer imposes. This abstraction gives us the ability to craft a more logically sound application that focuses on the behavior of the application rather than the data generated by it. The objects that we produce which are capable of being serialized over any service, have "true persistence ignorance", and can be shared as contract objects as they are not specific to the database implementation. This approach is also much more flexible as it is entirely dependent on the code that we write. This allows us to translate our objects into database records without modifying the structure of our application.