Picit félrevezető hibaüzenet EF alól foreach esetén

Hiba szövege SaveChanges-nél: New transaction is not allowed because there are other threads running in the session

Valóságban az történik, hogy foreach-csel lépdelsz végig az EF-es objektumokon (listán) és a nagy foreach-ben (a magban) valahol sikerül belemódosítani abba az objektumba, ahol lépdelsz...
Nem a "normál foreach exception" jön, de ez a baja, hogy megváltozott az objektum.

DateTime.Kind SQL-ből EF-fel felolvasott és jQuery-vel használt dátumoknál

DB-ben nem tárolódik a DateTime KIND értéke (Local, Utc, Unspecified). a jQuery viszont mindig normalizál UTC-re, így egy local stílusban tárolt DateTime megjárva a UI-t el fog mozdulni 2 órával UTC +2H esetén. Mivel az SQL-be nincs lenyomva ez az érték, ezért normalizálni kell UTC-re, hogy egy teljes kör megtétele után ne másszon el az érték:

Megoldás a Entity Framework-nél:
http://www.aaroncoleman.net/category/Database.aspx

Entity Framework hasznos infók

Találtam/gyűjtöttem pár jó könyvet neten, ami arról szól, hogy hogyan is álljunk neki EF-el fejleszteni, és hogy hogyan kell használni. Sokat nem írok róla, pár perc alatt lejön és a tartalomjegyzékből látszik a lényeg. Sajnos kevés szó esik arról (a tartalomjegyzékből ítélve, még nem olvastam végig őket), hogy hogyan célszerű használni az EF-t 3rétegű architektúrában, ezügyben még keresgélek.

1. Entity Framework learning guide (Janótól)

2. Programming Entity Framework

3. ADO.NET 3.5 with LINQ and the Entity Framework

Blog bejegyzés arról, hogyan kell szétvágni az entity model-t, ha sok entitásunk (db táblánk) van:
Working with Large Databases in Entity Framework

Többrétegű architektúráról is olvastam, hogy hogyan használják. Logikus amit olvastam, de egyelőre csak olyan eseteket, amikor a BL és a UI között egy WCF service réteg is van. Ebben az esetben úgy működik a dolog, hogy ugyebár a BL-ben vannak a metódusok, amivel hívjuk a DAL-t, vagyis be van referálva, és ott ismerjük az entitásokat is, és magát az ObjectContext-et is. Namármost ha a BL kódban (managerben) implementált metódust (ami pl visszaad egy product lsitát) kivezetjük egy WCF service-re, és megjelöljük a datacontract meg operationcontract attribútumokat, akkor amikor a proxyt generáljuk (svcutil) akkor a kliensen meglesznek az entitásaink a proxy generálás után. Tehát az entitások megvannak, a többi, ami az ObjectContext-ben van, annak hívható metódusai stb nem. Tehát pont az van ami kell.

Bővebben itt:
http://msdn.microsoft.com/en-us/magazine/cc700340.aspx
Hasonló cikk, többrétegűség + EF:
https://community.dynamics.com/blogs/cesardalatorre/comments/9584.aspx

További hasznos cikkek:
Data Access Objects with the Entity Framework
Managing Entity Framework ObjectContext lifespan and scope in n-layered ASP.NET applications

És újabb olvasgatásaim után lehet hogy megtaláltam a kulcsszót:
REPOSITORY PATTERN!!!

Tulajdonságai:
"Testability. Using the pattern we can create stubs that can replace the real data access objects. This can help us to test our business logic without concerning what the data access is doing.
Abstraction. Using the pattern we create an abstraction above our data access functionality. This abstraction can help us when we want to change the implementation of the data access without affecting our business logic code. For example, I had to change implementation of data access with a call to a web service. Using the pattern I only needed to change the object that I used and that is it.
Dependency Injection. Using the pattern we can use DI containers to inject the relevant object that we want to use in the code."

Azt hiszem ebben az irányban kellene keresgélni, repository-kat kell csinálni és azon keresztül érni el a domain object-eket. Még nem tudom hogyan kell, az a holnap (vagyis már ma) titka.