Wir entwickeln meist wenig frequentierte, aber hochspezialisierte Webanwendungen. Normalerweise verwenden wir L2S, EF oder nHibernate als Zugriffsebene und werfen dann Asp.Net MVC dorthin und in dem wir für normale Crud-Operationen den ISession/DataContext direkt abfragen, aber für fortgeschrittene Funktionen/Nebeneffekte stellen wir es in eine Art von Serviceschicht.Argumente für die Verwendung von WCF/OData als Zugriffsschicht anstelle von EF/L2S/nHibernate direkt
Jetzt habe ich darüber nachgedacht, die Daten über OData (WCF Data Service) zu veröffentlichen und diese von den Controllern (oder sogar von jQuery, wenn eine gute Template-Engine auftaucht) abzufragen und die Service-Operationen über einen WCF-Service zu veröffentlichen (oder als benutzerdefinierte Methoden im WCF Data Service?). Welche Vorteile/Nachteile birgt diese Architektur?
Erhalte ich etwas außer höherer Komplexität und Latenz? Bessere Trennungen von Bedenken (oder ist es nur eine Illusion)?
Bearbeiten: Kann es eine gute Idee sein, eine komplette Ajax-gesteuerte Lösung mit z. WCF RIA Services? Oder verliert man zu viel Flexibilität? Fühlt sich so an, als könntest du deine Ansichten komplett von deiner Logik loswerden, dann sollte man in der Lage sein, einfach reines HTML zu schreiben, nicht einmal ein asp.net MVC sollte benötigt werden? aber ich denke, es gibt viele neue Probleme, die entstehen?
schätzen Feedback zu verwandten Frage http://StackOverflow.com/questions/14769120/wcf-odata-for-multiplatform-Entwicklung – scotru