Self-Tracking-Entitäten im Vergleich zu POCO-Entitäten

Question

Wir starten ein neues webbasiertes Produkt, in dem wir unsere Geschäftslogik durch WCF-Services offenlegen wollen. Wir werden ASP.NET 4.0, C#, EF 4.0 verwenden. In Zukunft wollen wir iPhone-Anwendungen und WPF-Anwendungen auf Basis der Dienste aufbauen. Ich habe viel über POCO vs Self Tracking Entities (STE) gelesen und von meinem Verständnis her funktionieren die STEs nicht gut mit dem Webszenario. Kann jemand mehr Licht auf dieses Thema werfen?

Answer 1

Für mich ist STE absolut falsch Konzept. Es ist nur eine weitere Implementierung von DataSet.

• In ASP.NET-Anwendung müssen Sie STEs irgendwo zwischen Anforderungen speichern. In der ersten Anfrage werden Sie Ihre Datenquelle abfragen, um STE zu erhalten und Daten auf der Seite bereitzustellen. In der nächsten Anfrage (Postback) wollen Sie STE mit den zurückgegebenen Daten aus dem Browser modifizieren. Um das Tracking zu unterstützen, müssen Sie dasselbe STE wie in der ersten Anfrage verwenden = >. Sie müssen STE im Viewstate (wenn Sie ASP.NET WebForms verwenden wollen) oder Session speichern.
• STE ist für SOA oder Interoperabilität nutzlos. Tracking-Logik ist Teil von STE = es läuft auf dem Client. Wenn Sie STE im Service verfügbar machen, erwarten Sie sofort, dass die Client-Seite dieselben Tracking-Funktionen verwendet, die in der STE-Logik enthalten sind. Diese Funktionen werden jedoch nicht automatisch auf der anderen Seite bereitgestellt. In .NET haben Sie sie, weil Sie Baugruppen mit STEs teilen. Aber auf einer anderen Plattform müssen Sie Entwicklern erklären, wie Sie die STE-Logik implementieren, damit sie auf Ihrer Seite funktioniert. Dies wird wahrscheinlich der am meisten einschränkende Fall für Sie wegen der iPhone-Anwendung sein.

Answer 2

Self Tracking Entitäten funktionieren perfekt in einem MVC Web mit WCF-Szenario. Ich war an zwei Projekten beteiligt (eins in der Produktion, eins fast).

Mit POCOs verlieren Sie jede Änderungsverfolgung über die Verbindung, die eine Menge zusätzlicher Schmerzen verursacht, weil EF jetzt erneut nach Statusinformationen suchen muss. Wenn Sie EF und WCF STE verwenden, lösen Sie viele Probleme und machen Ihre gesamte Persistenz-Pipeline wirklich flüssig.

---

Können Sie dieses Claim zitieren? "STEs funktionieren nicht gut mit dem Webszenario"

Answer 3

Wenn dieser Dienst wird von jeder App verbraucht werden Sie direkte Kontrolle über nicht sollen, werden Sie wahrscheinlich mit EF zu tun (oder nHibernate oder Linq2Sql oder anderen Daten Persistenz-Management-Lösung) in Erwägung ziehen, etwas divorcing von Ihren Diensten und Ihren Datenübertragungsobjekten. Dies wird interne Änderungen von Kundenbränden isolieren. Kunden zu brechen ist normalerweise eine schlechte Sache.

Answer 4

Siehe http://msdn.microsoft.com/en-us/data/jj613924.aspx, da STEs nicht mehr empfohlen werden! Microsoft empfiehlt die Verwendung von ASP.NET Web API, WCF Data Services oder Entity Framework APIs (komplexe Ops)