Database Reference
In-Depth Information
Chapter 9
Using the Entity Framework in
N-Tier Applications
Not all applications can be neatly bundled into a single process (that is, reside on a single physical server). In fact,
in this ever-increasingly networked world, many application architectures support the classic logical layers of
presentation, application, and data and also are physically deployed across multiple computers. While
logically
layering
an application on a single computer can be accommodated in a single Application Domain without much
concern for proxies, marshalling, serialization, and network protocols, applications that span from something as small
as a mobile device to an enterprise application server found in a data center need to take all of these considerations
into account. Fortunately, the Entity Framework together with technologies like Microsoft's Windows Communication
Foundation, or the Microsoft Web API framework, are well suited for these types of n-Tier applications.
In this chapter, we'll cover a wide range of recipes for using the Entity Framework with n-Tier applications.
To be clear,
n-Tier
is defined as an application architecture in which the presentation, business logic, and data
access processing tiers are physically separated across multiple servers. This physical separation can help improve
the scalability, maintainability, and future extensibility of an application, but often can have a negative impact on
performance, as we are now crossing physical machine boundaries when processing application operations.
N-Tier architecture adds some special challenges to the change-tracking features of Entity Framework. Initially,
data is fetched with an Entity Framework context object that is destroyed after the data is sent to the client. While on the
client, changes made to the data are not tracked. Upon an update, a new context object must be created to process
the submitted data. Obviously, the new context object knows nothing of the previous context object, nor the values
of the original entities. In this chapter, we'll look at some approaches that you can implement to help bridge this gap.
In past versions of Entity Framework, a developer could leverage a special template entitled Self-Tracking
Entities, which provided built-in plumbing to help track changes to disconnected entity objects. However, in Entity
Framework 6, the self-tracking entity approach has been deprecated. While the legacy ObjectContext will support
self-tracking entities, the more recent DbContext object does not. The recipes in this chapter focus on basic create,
read, update, and delete operations you'll typically use in your n-Tier applications. Additionally, we'll take a deep dive
into entity and proxy serialization, concurrency, and working with the unique challenges of tracking entity changes
outside the scope of an object context.
9-1. Updating Single Disconnected Entities with the Web API
Problem
You want to leverage REST-based Web API services for inserts, deletes, and updates to a data store. Additionally,
you want to implement the code-first approach for Entity Framework 6 to manage data access.
In this example, we emulate an n-Tier scenario where a stand-alone client application (Console Application) is
calling a stand-alone website (Web API Project) that exposes REST-based services. Note that each tier is contained in a
separate Visual Studio Solution, so as to allow for easier configuring, debugging, and simulation of an n-Tier application.
