- Floating Topic
-
Object Context
-
Entity State Enumeration
- Added (After Save = Unchanged))
- Deleted (After Save = Detached)
- Modified (After Save = Unchanged)
- Detached (After Save = Added)
- Unchanged
-
Object Context Life Cycle
- Memory Usage (Can be grow better to share)
- Dispose (Using Block is a good approach since it implemented IDisposable)
- Cost of construction (Too Low no worries of considering)
- Thread Safety (Never share object context)
- Stateless (Use using block approach)
- Transactions
- Concurrency
-
Self-Tracking Entity
-
Tracking Methods
-
aaaaazz
- Support WCF (automatically deserialized)
- StopTracking Method
- MarkAs Method
- MarkAsAdded Method
- MarkAsModified Method
- MarkAsUnchanged Method
- AcceptChanges Method
- Subtopic 10
- MarkAsDeleted Method
- Cant use proxy types because it is not use tracking details and need to reference domain dll directly
- ObjectContext needs to use Using Block
- Data Services
-
Query
-
Linq to Entities
-
from, where, select
- SELECT value c FROM Contacts AS c
-
EntitySQL
- Using SQL in Entity SQL
- Object Queries using Linq
- Reading Query Plan
-
POCO
- SaveChanges method Calls DetectChanges that help to identify changes
- Properies should be virtual for Lazy Loading that uses Dynamic Proxies
-
Dynamic Proxies
- Properties should be virtual
- Runtime inherit POCO class and create dynamic proxy that gives the functionality of EntityObject
- Provide Change Notification and Lazy Loading
-
WCF
- Lazy Load = false for heavy Load on serializing
-
Exposing Data as a Web Service
- Http Post - Insert
- Htttp Get - retrieve
- HttpDelete - Delete
- Http Put - update
- Short Lived ObjectContext
- Uses OData (Protocol Open Data Protocol)
-
Entity Framework First Release
- EDMX Criticized by Agile Developers
- Hard to Unit Test: Methods interact with Database
- Classes are Tightly Bound with EF
- All classes need to inherit from EntityObject that responsible for providing relationships and tracking
- ObjectContext remove these dependencies by acquiring relationships and change tracking
-
EF Inheritance
-
Table Per Hierarchy
-
Use Discriminator
- Not Normalized
- Better Performance, Less Join
- All Properties are nullable
-
Table Per Type
-
Table for Each specific Type; Abstract class has common properties, inherited type has specific properties
- Joins are high
- Create Indexes to tune performances
- Id is primary key for all tables
-
Table Per Concrete Type
- Duplicate the data columns
- If you want to access abstract class properties values have to query all concrete classes
-
Data Loading
-
Lazy Loading
- Best Practise Turn off use eager Loading
-
Eager Loading
- Use include with Query
-
Explicit Loading
- Use Load method to load
- Performance