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 theconnection open until all rows are fetched one by one.
• DataSet is Disconnected Architecture since all the records arebrought at once and there is no need to keep the connection alive.
• DataAdapter acts as a bridge between the Connected andDisconnected Objects. It manages connections between Data Source andDataset 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

ADO.Net

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

I think a common real-life analogy is making a phone call. If you want a friend to talk you through the way to his home while you're driving, you'll prefer the 'connected mode': during the phone call you talk back and forth until you are there. It would be too time-consuming to start a new phone call for each instruction.
But if you ask your mother, who lives two blocks away, to check whether you closed your kitchen window you'll call her and she'll go check and call you back: 'disconnected`. In the mean time you'll continue doing whatever you were doing.

In that sense, Entity Framework always operates in disconnected mode. Each database operation by EF opens and closes the database connection (unless you explicitly override this behavior).

Software architecture

But 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.

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 you confusion...

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. Lerman and Miller describe the whole process in their book Programming Entity Framework: DbContext chapter 4: Working with Disconnected Entities Including N-Tier Applications.

And now your question

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

can be answered this way:

• 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 there's a choice. This choice takes us to the area of context life cycle management. Much has been said about this. An undeniable fact is that 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, so even in data-heavy 1-tier applications the disconnected (detached) scenario should be seriously considered.