Should I use the same context everywhere when using the Repository Pattern with Entity Framework 3.5 and MVVM?

c# entity-framework mvvm repository-pattern wpf

Question

I'm working on a File System for a Database. I'm using

  1. 3.5.Net Framework
  2. 3.5 Entity Framework
  3. the MVVM pattern and WPF

The project involves many assembly, all of which use the same model.

One assembly—call let's it a "server"—uses the same model and solely adds data to the database using EF. The data is read and written by other components, including the user interface. The modifications performed by the server ought to take effect right away in other assemblies.

Self-referential tables in the database allow each object to have one OR no parents, as well as (maybe) some children. Repository patterns are what I want to employ since they can provide some kind of solution for dealing with this hierarchical structure.

I've previously read about this on pages 40 to zz. Everywhere it uses the same context and entities.

Should I use the same context across the board? is the question I have. What are the benefits and drawbacks of such action?

1
2
11/16/2017 7:23:39 PM

Accepted Answer

The Application Framework for WPF (WAF) example for BookLibrary demonstrates how to combine WPF MVVM with Entity Framework. The layers are divided up into distinct assemblies.

Perhaps you are seeking for that.

4
4/15/2010 5:49:42 PM

Popular Answer

I believe the objectcontext should be utilized as required and then discarded. Therefore, you should definitely wrap it in a unit of work interface and have a unit of work factory ready to build the unit of works as required.

On your query regarding the entities that indicate changes across "assemblies," Your objects don't really exist in assemblies, which is the problem. They are a part of memory.

Therefore, to ensure that changes are reflected across the application, you must either keep a reference to the same object throughout the whole program. Alternately, you might set up a notification system such that when an entity or group of entities is modified, the opposite side of your app is alerted and the data is refreshed.

The drawback of maintaining a single context is that every time you run a query on it, the object context expands to include the entities that were loaded from the database. This results in significant memory usage for a program that runs for a long time.

The drawback of creating a new context for each call to the repository is that each one results in a new copy of the data. Since the repository should only be concerned with storing and loading data, not with managing concurrency or data duplication between layers, this shouldn't be a problem.



Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow