# Entity Framework in the Enterprise on Pluralsight

What I want to know how to do in entity framework:

• Create
• High speed database contexts
• Object rich database contexts
• Dynamically composable database contexts for when pre-built don’t exist
• Understand
• Best path
• Risks and Challenges

With those questions in mind I watched Entity Framework in the Enterprise: Incorporating Entity Framework into applications that are architected for the enterprise.

Personal notes follow.

## 2 Notes

### 2.1 Architecting the Data Layer (Overview) 20:38

• This lecture is how to do real work
• Where EF fits into you architecture
• Repository Patterns
• Unit of Work
• Bounded contexts
• Unit testing with EF
• Understand what you are being taught; feature demonstrations are not best-practices
• Stack/Areas
• Typically
• UI
• Services
• Repository/unit-of-work
• Data
• Database
• Keep EF in the data layer and no where else using Repository Pattern
• MVC looks nice
• The topic of concern of this lecture is that of large enterprise applications
• Start listening at 5m for 58s if you want proof that Lerman is legitimate
• Normal separation of concerns OO stuff
• LINQ belongs in the repository/unit-of-work layer
• Repository/unit-of-work is an abstraction against storage mechanisms
• Your have to make a good educated decision, not the tool’s choice
• You ought to unit test your data layer, she will show how to do so without EF
• Domain Driven Design book introduce st he Bounded-DB-Context idea
• This is exactly what I was asking up in 1
• This lecture covers the architecture of the data layer and its friends and is
not about the entire system architecture

### 2.2 Bounded DbContext 50:40

• Overview
• DDD and a bounded context
• Code first implementation
• Small models
• Sharing objects across models and context instances
• DDD is about communication with the SMEs
• Bounded context
• Delimits the applicability of a particular model
• Gives team members a clear and shared understanding of
• What has to be consistent
• What can develop independently
• Problem is primarily about maintenance not performance
• Models are bounded by the context where the live
• Will see objects appear in multiple context classes
• Use References instead of the objects
• Reference classes vs inheritance
• The impact of having multiple contexts
• CodeFirst DB context will pull more objects in than you expected
• Use this as for exposure/navigation control
• Kind of a subtle point, the way I heard it, you ought to
• Understand EF
• Refine their implementations to obtain desired traits
• Moving data across contexts
• This is a very important topic
• Transitional logic per property moving between context boundaries
• Transition by object id
• Simple address change example quite nice
• Get its ID
• Work with it
• Transition by object instance
• Need a memory model of objects instances and database context and how you
• Need a comfort level understanding how the DbContext manages that memory
and how it will reason about and handle entity instances as you pass them
into different DbContexts
• Nice performance tweak to use in memory version of the entity
• How timely may we assume that is OK?
• Why not lazy load every property instead of doing Reference classes?
• You may ask model-builder to bring in any entity type
• Of course you can
• It is entirely up to you
• Either rely on auto-configuration or manual-configuration to get what you want
• Structure tip (sounds like a gem)
• Each context belongs in it’s own project
• Put mappings into their own project, too
• Reference mappings and contexts from the same project to initialize the context

### 2.3 Repositories and Unit of Work 1:00:41

• Encapsulate repetitive data access code
• Subtle point about the power of the repository irrespective of its back-end
• Questions posed about repository-context relationship reveals flavor of the pattern
• One repository per type?
• One repository per object graph?
• One repository per context?
• Where do all of the evaluations live?
• There is a MVC scaffolding to build contexts for yuo
• T4Scaffolding template
• A .NET Repository is a Java DataAccessObject
• Repositories seems to be responsible
• For the LINQ exposure/integration of data
• So the repository handles usage preference abstractions, too?
• EF
• must have an UpdateOrAdd ala Hibernate
• Of course it does InsertOrUpdate
• Must load am object into a context then Remove it to send delete to DB
• This is really a big deal grokking the implementation details and
• Repository is not a stupid-abstraction or OO-pontification, it is a place to
capture decisions about how you want your system to perform for this
implementation given the requirements
• When you pass LINQ expressions to a repo, they are delegated to SQL Server
• Bone up on LINQ
• InsertOrUpdate seems to be an acceptable way to merge back into a context?
• Separate methods for singular vs. graph insert
• Attaching disconnected graphs
• Add will insert every object as new
• Attach expects all entity state to be unchanged
• Example of something of what unsure
• How to handle entity re-attach it seems?
• Manual key settings instead of working in a context? Of course not.
• You must thoroughly grok EF to understand how to implement your repository
• Graph attachment usage patterns
• For a graph of entirely new objects
• DbSet.Add is all you need
• For a graph where the root is new and everything else is existing and unchanged
• All items in the graph are modified
• Set State=Modified for the root and every related item
• DbSet.Add and State=Modified and the context will handle it
• Seems very low level to be dealing with
• Managing object state for merging-success by hand
• Like the presenter said, demo-ware is demo-ware

• Skipped

## 3 Conclusion

• This series is a nice overview of one way to implement the repository pattern.
• Generally my questions were answered since they were not detailed questions

## One thought on “Entity Framework in the Enterprise on Pluralsight”

1. That’s really shedwr! Good to see the logic set out so well.