connected model and disconnected model in EF

Question

I'm confused a lot about connected model and disconnected in entity framework .

I was using traditional ADO.net (DataReader for connected model and DataAdapter for disconnected model) and all I know that I use connected model when I have many users need to update or insert together and the disconnected model in a few circumstances when I need to send the data to other process make some operations on the data in memory and send them back to the db .

Now I read some articles about connected model and disconnected model in EF and I'm confused why should I attach explicitly the entities to the context in disconnected model ? I had read also that the default behavior in web is disconnected model and in WPF is connected model !

---

• Could someone explain in easy manner with an an analogy of real life what's the difference between the two models?
• How we could handle both models in EF with simple example?
• Is there a relationship between the type of app (web form , MVC, WPF, WCF) and the dedicated model used in the EF?
• When to use connected model and when to use disconnected model (using EF) ?

Anthem

this site has several references to "disconnected" that I found helpful. entityframeworktutorial.net/… or here is a "fishing for stuff" link : google.com/… – Brooklynese

Answer 1

A Background

The ADO.NET Framework supports two models of Data Access Architecture:

1. Connection Oriented
2. Disconnected

In Connection Oriented Data Access Architecture the application makes a connection to the Data Source and then interact with it through SQL requests using the same connection (e.g. an open connection must be maintained between your application and the Data Source even when it is not using any Database Operations).

Connected architecture is when you constantly make trips to the database for any CRUD (Create, Read, Update and Delete) operation you wish to do. This creates more traffic to the database but is normally much faster as you should be doing smaller transactions.

It's built on the classes Connection, Command, DataReader and Transaction.

In Disconnected Data Access Architecture the ADO.net uses in-memory data store that can hold multiple tables at the same time (they're fetched before).

Disconnected architecture is a method of retrieving a record set from the database and storing it giving you the ability to do many CRUD (Create, Read, Update and Delete) operations on the data in memory, then it can be re-synchronized with the database when reconnecting.

It's Built on classes Connection, DataAdapter, CommandBuilder, DataSet and DataView.

---

Some key Classes of Connected and Disconnected architecture

• DataReader is Connected Architecture since it keeps the connection open until all rows are fetched one by one.
• DataSet is Disconnected Architecture since all the records are brought at once and there is no need to keep the connection alive.
• DataAdapter acts as a bridge between the Connected and Disconnected Objects. It manages connections between Data Source and Dataset by fill the data from Data Source to the Dataset.

which one is better in desired situation?

Connected Mode

• connection oriented
• we read data from a database by using a DataReader object
• Its methods provide faster performance
• It can hold the data of single table
• It's read only, we can't update the data

Disconnected mode

• It's disconnected connection oriented.
• we read data from a database by using a DataSet object.
• It get low in speed and performance.
• It can hold multiple tables of data.
• we can perform all option as like update, insert, delete etc.

---

Answer of your questions

Now I read some articles about connected model and disconnected model in EF and I'm confused why should I attach explicitly the entities to the context in disconnected model? I had read also that the default behavior in web is disconnected model and in WPF is connected model !

Web application could be connected or disconnected, and, in fact ASP.NET applications are disconnected, due to ADO.NET disconnected model. Disconnected model is getting more popular due to simple implementation and easier troubleshooting. Good design with ASP.NET application would close all the database connections as soon as data manipulation is complete regardless if it is 15 hit per month or 15 hits per second.

Could someone explain in easy manner with an an analogy of real life what's the difference between the two models?

Yes, Suppose you have some important tips to tell/aware a friend. Disconnected means the way you've awaited to see him or you're spending time to obtain more tips to say. Connected is the way when you live with him or having an online/RealTime communication to him for telling every tip each time you want.

How we could handle both models in EF with simple example?

EF uses the Disconnected model. since you work with data and make desired changes and then you perform the SaveChanges :)

Is there a relationship between the type of app (web form , MVC, WPF, WCF) and the dedicated model used in the EF?

It's based on application logic. RealTime applications need to be connected as they need on-time propagation and updates rather than another application types.

When to use connected model and when to use disconnected model (using EF) ?

I've answered this. Just I would like to say By keeping connections open for only a minimum period of time, ADO.NET conserves system resources and provides maximum security for databases and also has less impact on system performance. It's based on your application strategy/type, you can make a good decision yourself.

Update:

but if i was in a disconnected model, Could you tell me how the EF can handle multiple operations (INSERTs,UPDATEs,DELETEs) from many users at the same time?

Take a look at ObjectStateManager which is responsible for everything related to object tracking in the context. If some users perform concurrent updates to the same entry, By default, the Entity Framework implements an optimistic concurrency model. This means that locks are not held on data in the data source between when the data is queried and the data is updated. The Entity Framework saves object changes to the database without checking for concurrency. For entities that might experience a high degree of concurrency (like banking system), we recommend that the entity define a property in the conceptual layer with an attribute of ConcurrencyMode="fixed", as shown in the following example:

<Property Name="Status" Type="Byte" Nullable="false" ConcurrencyMode="Fixed" />

When this attribute is used, the Entity Framework checks for changes in the database before saving changes to the database. Any conflicting changes will cause an OptimisticConcurrencyException which can also occur when you define an Entity Data Model that uses stored procedures to make updates to the data source. In this case, the exception is raised when the stored procedure that is used to perform updates reports that zero rows were updated. For more information visit Saving Changes and Managing Concurrency

Platonism

but if i was in a disconnected model,Could you tell me how the EF can handle multiple operations (INSERTs,UPDATEs,DELETEs) from many users at the same time – Anthem

@just_name Good question :) I'll put your answer at the last of my post as soon as possible. – Platonism

@just_name I finally put the answer of your last question – Platonism

By default, the Entity Framework implements an optimistic concurrency model. No, by default it doesn't implement any concurrency model. Applying ConcurrencyMode="fixed" is referred to as optimistic concurrency, but that's way to simple for systems with distributed transactions. – Barham

@GertArnold So what happened?! Is it wrong what I say (based on EF reference)? Or, Are you meaning something else? – Platonism

@GertArnold I only placed the contents of official EF website in my post where its link is placed too! so you mean the official site says wrong?! – Platonism

Well, that's confusing, at best! The common definitions of optimistic concurrency always mention something like "Before committing, each transaction verifies that no other transaction has modified the data it has read." (Wikipedia). And that's why this model throws OptimisticConcurrencyExceptions when implemented in EF. – Barham

Answer 2

ADO.Net

'Connected' and 'disconnected' in ADO.Net are about the database connection. A DataReader always has an open connection, DataSet/DataAdapter connect to the database when necessary.

In ADO.Net terms, Entity Framework always operates in disconnected mode. Each database operation by EF opens and closes the database connection (unless you explicitly override this behavior). That's the only thing that matters here. There's no need to expand on the details of (dis)connected ADO.Net. It suffices to say that generally, it's not recommended to keep database connections open for a long time.

Software architecture

In software architecture, 'connected' and 'disconnected' usually refer to 1-tier vs. N-tier. In a 1-tier application, for instance a WPF application, the user interface and the data access layer (DAL) run in the same application process. The UI is 'connected' to the DAL. Not that it will always have an open connection to the database, but the database is always available. Objects fetched from the data store by the DAL can be processed in the UI and the same objects can be returned to the DAL and get saved to the data store (for which a new database connection is used).

In an N-tier application the UI is separated, 'disconnected', from the data access layer by a network connection. Let's say the DAL is part of a web service. A web service will typically be stateless: it produces responses and forgets about them. Also, the objects will be serialized and deserialized at both sides of the connection. When the response enters the wire the objects are gone.

Entity Framework

As you'll suspect by now, in the EF world 'disconnected' refers to the latter meaning, the N-tier application.

In a 1-tier application you could choose to have a context (a DbContext) that produces entities and saves the same entities when any modifications are made in the UI. No need to re-attach them to a new context. (Whether it's sensible to keep a context alive that long is a different question).

In N-tier applications a context either produces entities or saves entities, not both. It produces entities that get serialized and the context is disposed. Entities that return from the client application are deserialized and re-attached to new context instance that saves their changes. This is the source of your bemusement...

why should I attach explicitly the entities to the context in disconnected model

It all makes sense if you read 'disconnected' in the architectural connotation. In the Entity Framework docs there's an entire chapter on this topic.

Therefore, your question

When to use connected model and when to use disconnected model (using EF)

can be answered as follows:

• From an ADO.Net point of view, there's no choice (save some special cases), EF works disconnected (as in: doesn't leave a connection open).
• From an architectural point of view there's no choice when the application is N-tier: it's always disconnected (as in: detached and re-attached, entities aren't created and saved through the same context).
  Only in 1-tier applications one may opt for a connected scenario. In that case, context life cycles should be managed carefully. A context gets slow and memory-consuming when it contains 'many' objects. It's very hard to keep any application snappy when contexts have long lifespans. In my opinion, even in 1-tier applications the disconnected scenario should be favored.

Barham

but if i was in a disconnected model with no choice as you said !,Could you tell me how the EF can handle multiple operations (INSERTs,UPDATEs,DELETEs) from many users at the same time ? What if i develop a banking system or purchasing module ,How could EF disconnected model handle this? – Anthem

That's a very broad question you're asking here. Usually optimistic concurrency strategies are used in multi-user environments, but for banking systems this is not enough, obviously, you'd need locking strategies and distributed transactions. But that's way too complex to describe in one answer (and for me, frankly, without thoroughly studying it first). – Barham

What i meant .is concurrency strategies related to the model(connected,disconnected)?! – Anthem

There is no relation actually. The question whether or not to apply concurrency strategies, and which one, doesn't depend on the application model. The implementation will be different when working with detached entities than in a 1-tier application, but again, that's off-topic here. – Barham