Laden...

Problem in Client-Server-Anwendung mit WCF und ADO.Net EntityFramework

Erstellt von GIGGS vor 14 Jahren Letzter Beitrag vor 14 Jahren 6.300 Views
G
GIGGS Themenstarter:in
67 Beiträge seit 2009
vor 14 Jahren
Problem in Client-Server-Anwendung mit WCF und ADO.Net EntityFramework

Hallo liebe Leutz,

ich habe eine Anwendung angefangen, die clientseitig durch mehrer Personen genutz wird, sei es im Office (Lan) oder draußen (WLan). Alle User greifen auf einen SQl Server zu, in dem die Daten gepflegt, geändert und gespeichert werden.

Problem ist nun folgendes:

Wenn ein Client nun Daten bearbeitet, die über einen WCF-OperationContract geholt wurden und diese nun speichern möchte; sprich wieder eine WCF-Übertragung an den Server stattgefunden hat, gibt es das Problem nur die wirklich geänderten Datensätze in der Datenbank zu ändern. Wie mache ich das?
Der Client kennt die Datenbank nicht, denn die ist nur im Service. Und da ich nicht mit nem DataContext (DatenbankEntities) im Client arbeite, kann ich im Service nicht einfach DataContext.SaveChanges(); aufrufen, was in einer reinen ClientAnwendung möglich wäre.

Hat jemand von euch ähnliche Probleme? kennt jemand eine performante Lösung mit dem EF für eine solche Anwendung?

Vielen Dank im Voraus und
mit freundlichen Grüßen

GIGGS

kleines Bsp:

Client:


private ObservableCollection<User> _users;
        public ObservableCollection<User> Users 
        {
            get
            {
                return _users;
            }
            set
            {
                RefreshUserDataContext();
                if (null != this.PropertyChanged)
                {
                    PropertyChanged(this, new PropertyChangedEventArgs("Users"));
                }
            }
        }

private void RefreshUserDataContext()
        {
            using (ServiceClient proxy = new ServiceClient())
            {
                if (_users == null)
                {
                    _currentUsers = proxy.GetAllUsers();
                }

                _users = proxy.GetAllUsers().ToObservableCollection();
            }
        }

private void AddNewUser()
        {   
            User u = new User();
            InitNewUser();

            using (ServiceClient proxy = new ServiceClient())
            {
                proxy.AddUser(u);
                Users = proxy.GetAllUsers().ToObservableCollection();
            }
        }

ServiceInterface IService:


[OperationContract]
void AddUser(User newUser);

[OperationContract]
IEnumerable<User> GetAllUsers();

Service:


public void AddUser(User newUser)
        {
            using (DBEntities DataContext = new DBEntities())
            {
                DataContext.AddToUser(newUser);
                DataContext.SaveChanges();
            }
        }

public IEnumerable<User> GetAllUsers()
        {
            return new DBEntities().User;
        }

G
GIGGS Themenstarter:in
67 Beiträge seit 2009
vor 14 Jahren

im obigen Bsp ging es noch, jedoch beim Update von vorhandenen Datensätzen ist es nicht auszuhalten, was Performance angeht:

Client:
(es wird ein User über GUI TextBoxex etc geändert; Binding an SelectedUser)


private void UpdateUser()
        {
            using (ServiceClient proxy = new ServiceClient())
            {
                proxy.UpdateUser(SelectedUser);
            }
        }

Service:
(im Interface wieder ein OperationContract)


public void UpdateUser(User changedUser)
        {
            using (DBEntities DataContext = new DBEntities())
            {
                DataContext.Attach(changedUser);
                changedUser.SetAllModified(DataContext);
                DataContext.SaveChanges();
            }
        }

SetAllModified ist ne ExtensionMethod, nicht die vorgefertigte vom EF bzw MS.
Wenn es jetzt nicht nur ein User sondern eine Liste von Usern wäre, hätte man die nächste Foreach-Schleife, in der für jeden User SetAllModified(DataContext) aufegrufen wird.
ich würde gerne nur SaveChanges() aufrufen.
Ist dies möglich?

Liegt es am EF oder an WCF, dass diese performanceProbleme nötig sind?

MfG GIGGS

3.003 Beiträge seit 2006
vor 14 Jahren

Liegt es am EF oder an WCF, dass diese performanceProbleme nötig sind?

Wo sind da Performanceprobleme? Da werden nur ein paar Eigenschaften eines Objekts geändert - ist nicht so, dass das wahnsinnig teuer wäre.

Im Prinzip hast du dieselben Probleme, die momentan hier diskutiert werden:
Entity Framework: Wie Entity "Inserten" wenn diese eine Relation enthält.

Du musst ein vom Kontext getrenntes Objekt (mit seinen Sub-Eigenschaften) anhand des Entitykeys wieder an einen anderen Kontext hängen. Dafür kannst du

  • (mit SetAllModified) den EntityState manipulieren (geht, wird aber gern mal unübersichtlich)
  • anhand des Keys das Objekt im Entitykontext heraussuchen, und die Eigenschaften setzen, die im übertragenen Objekt gespeichert sind
  • eine Schnittstelle definieren, die nicht die Entitäten, sondern nur ihre Eigenschaften überträgt
  • ein "flaches" Objekt anstelle der Entitäten übertragen

Möglichkeiten sind genug da 😉.

EDIT: nur SaveChanges() ? Nunja, dann speicherst du eben die Änderungen, die zu diesem Zeitpunkt im aktuellen Entitätskontext aufgetreten sind. Sprich: keine.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

3.728 Beiträge seit 2005
vor 14 Jahren
Ado.net

Hallo GIGGS,

das ADO.NET Entity Framework ist für den Einsatz in verteilten Anwendung nicht ideal. Es gibt zwar Lösungswege für Dein Problem (LaTino hat ja einige genannt), aber diese sind sehr aufwändig zu implementieren und sind ein Grauß, was die Performance angeht. Besonders Batch-Operationen (mehrere Datensätze in einem Rutsch anlegen, ändern oder löschen) sind nur mit viel Kompromissen und behelfmäßigen Workarounds möglich.

Mit .NET 4.0 sind aber Verbesserungen in diesem Bereich angekündigt (Stichwort Self Tracking Entities http://blogs.msdn.com/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx). Das "Fette", was OR-Mapper-Fans an (typisierten) DataSets stört, kommt wird dabei durch´s Hintertürchen nachgerüstet und von POCOs bleibt nicht mehr viel übrig. Ein OR-Mapping-Ansatz mit echten POCOs funktioniert in verteilten Anwendungen nicht optimal.

Ich kann Dir versichern, dass Du mit herkömmlichem ADO.NET und typisierten DataSets schneller zu besseren Ergebnissen in Deinem Projekt kommst. Hier findest Du eine komplette Anleitung, wie Du effektiv n-Tier Anwendungen mit typisierten DataSets als DTOs erstellst: http://msdn.microsoft.com/de-de/library/bb384587.aspx

Das Entity Framework ist super für Fat-Clients oder ASP.NET-Anwendungen, aber NICHT für verteilte Anwendungen, deren Komponenten über WCF, Webservices oder Remoting miteinander kommunizieren. Da die überwiegende Mehrheit der Entwickler keine verteilten Anwendungen erstellt, haben die meisten EF-Anwender diese Probleme nicht.

3.003 Beiträge seit 2006
vor 14 Jahren

Prinzipiell richtig, auch, wenn ich den Performance-Graus nicht im geringsten nachvollziehen kann 😉.

Für verteilte Anwendungen, in denen hauptsächlich Datenlisten übertragen werden und beim Ändern (am besten) ein einziges Objekt übertragen wird, kann ich's nur empfehlen. Ein solches Szenario sind die angesprochenen ASP.NET-Anwendungen, ein anderes wären Netzwerke von (restful) (WCF-)Services. Wie immer - das richtige Werkzeug für den richtigen Einsatzzweck. Dass MS das Entity Framework teilweise als Allheilmittel anpreist, hilft dabei leider nicht wirklich - aber wenn man sich hauptsächlich in den genannten Szenarien bewegt, ist man heilfroh, die Datasets hinter sich gelassen zu haben.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

G
GIGGS Themenstarter:in
67 Beiträge seit 2009
vor 14 Jahren

Hallo,

schon mal vielen Dank für eure Antworten.

Ich bin jetzt auch schon an dem Punkt, wo ich abwege den Schritt mit DTO und ADO.Net zu arbeiten.
Ich finde nur den Komfort, den man hat natürlich super:
Klassenerzeugung und das nutzen dieser Klassen, Navigation-Properties zu Relationen zwischen Tabellen, etc

MfG GIGGS

3.003 Beiträge seit 2006
vor 14 Jahren

Kommt halt drauf an, wie du die Kommunikation zwischen Server und Client aufziehen möchtest.

Userliste an Client übertragen, dort am besten noch per DataBinding arbeiten und erst nach dem Bearbeiten mehrerer User die komplette Liste zurückübertragen wird mit EF (unter Umständen) ein kleiner Handstand.

Userliste an Client übertragen, und nach jeder datenverändernden Aktion den User auf dem Server aktualisieren - das geht mit EF schon deutlich schöner.

Ersterer Fall macht sich vermutlich mit ADO.NET ganz gut.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

3.728 Beiträge seit 2005
vor 14 Jahren

Für verteilte Anwendungen, in denen hauptsächlich Datenlisten übertragen werden und beim Ändern (am besten) ein einziges Objekt übertragen wird, kann ich's nur empfehlen.

Man kommt aber mit einem einzelnen Objekt jenseits von Hello World nicht aus. Wenn ich z.B. einen Auftrag einbuche besteht der aus einem Kopfdatensatz und x Positionen. Da alles innerhalb einer Transaktion gebucht werden muss, bringt es nix, Kopfdatensatz und dann jede Position einzeln zum Server zu übertragen. Der Dienst ist statuslos und braucht alle Daten auf einen Rutsch. Nur dann kann er alles in einer Transaktion zusammenfassen.

Natürlich kann man das auch mit dem EF implementieren, was dann in etwa so aussehen würde:


[Serializable]
public class OrderContainer
{
     public OrderHead Head
     {
          get;
          set;
     } 

     public IList<OrderDetail> Details
     {
          get;
          set;
     }
}

public interface IOrderService
{
     OrderContainer GetOrderByID(Guid orderID);

     OrderContainer CreateOrder(OrderContainer container, Transaction transaction);

     OrderContainer UpdateOrder(OrderContainer container, Trancaction transaction);

     OrderContainer DeleteOrder(OrderContainer container, Trancaction transaction);
}

Das ist aber sehr aufwändig. Vor allem, da die automatische Serialisierung des kompletten Objekt-Graphen nichts bringt, da es keinen RowState gibt. Deshalb muss ich am Client manuell zusammenpacken, was ich genau anlegen, ändern oder löschen will.

Mit typisierten DataSets würde das so aussehen:


public interface IOrderService
{
     OrderDataSet GetOrderByID(Guid orderID);

     OrderDataSet SaveOrders(OrderDataSet orders, Transaction transaction);
}

Das ist viel weniger Code (wenn ich den kompletten Implementierungs-Code vergleiche, ist der Unterschied noch viel drastischer), bietet mehr Komfort (z.B. beim DataBinding auf dem Client), hält die API übersichtlich und hat den Effekt, dass man früher Feierabend hat und das Projekt schneller am laufen ist. Dem Kunden ist es herzlich egal, ob die Daten mit DataSets oder Objekten übertragen werden. EF bringt in verteilten Anwendungen derzeit einfach nur Nachteile. Es gibt deshalb eigentlich nur zwei Argumente, warum es Leute, für verteilte Anwendungen trotzdem einsetzen:*Ich habe vom Chef/Auftraggeber die Vorgabe (warum auch immer) es mit dieser Technologie zu machen und daran gibt's nix zu rütteln *Ich will unbedingt das tolle, neue EF einsetzen, weil im Internet alle sagen DataSets wären böse (Wenn die große Masse aus dem Fenster springt, kann das ja nicht verkehrt sein)

Selbst wenn .NET 4.0 da ist und EF mittels Self Tracking Entities über einen nachgerüsteten RowState verfügt, kann ich weiter spotten, denn da gesteht Microsoft ein, dass es ohne RowState und damit ohne fette Zusatzdaten nicht geht. Man baut das Prinzip von DataSets/DataTables einfach nach und da vorne OR-Mapper draufsteht, sreien alle "Hurra". Das finde ich seltsam.

3.003 Beiträge seit 2006
vor 14 Jahren

Nun kenn' ich deinen Kreuzzug gegen das EF ja schon ein bisschen 😉.
Tatsache ist, dass es so wie von dir skizziert, nicht aussehen muss. Gerade das, was du als Aufwand bemängelst, wird (hier bei uns) längst nicht mehr von Hand gemacht - um den Sch....Kram kümmer ich mich nicht. Das war einmal Aufwand, um die Dienste entsprechend generisch zu gestalten - das war's dann aber auch. Dafür bin ich komplett unabhängig von irgendwelchen Datenbanken und kann beim programmieren wirklich objektorientiert arbeiten, statt mich mit DataSets herumzuärgern.

Ja, es ist Aufwand. Ja, den sollte man nur betreiben, wenn die Wiederverwendbarkeit so hoch ist, dass sich die Anfangsinvestition lohnt.

Und das hier:

Es gibt deshalb eigentlich nur zwei Argumente, warum es Leute, für verteilte Anwendungen trotzdem einsetzen:

* Ich habe vom Chef/Auftraggeber die Vorgabe (warum auch immer) es mit dieser Technologie zu machen und daran gibt&#39;s nix zu rütteln  
* Ich will unbedingt das tolle, neue EF einsetzen, weil im Internet alle sagen DataSets wären böse (Wenn die große Masse aus dem Fenster springt, kann das ja nicht verkehrt sein)

...nunja, ohne Worte. Es wäre manchmal vielleicht angebracht, einen Gang zurückzuschalten.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

G
GIGGS Themenstarter:in
67 Beiträge seit 2009
vor 14 Jahren

Hallo,

mich würede wirklich mal interessieren, wie du das umgesetzt hast LaTino?
Es scheint ja bei dir gut zu funktionieren.

Wenn du jetzt z.B. Massen von Daten in einem Grid hast und der user kann dort Daten ändern wie er möchte, wie würdest du das dann hinbekommen, alle einzelnen geänderten daten ordentlch über WCF an den Service zu schicken und im Service nur die veränderten Properties deines Entities zu ändern?

Dann bei zum Bsp. einem Button nur noch im Service dataContext.SaveChanges() aufzurufen um dann die Daten wirklich erst in der DB zu ändern, da er ja auch Cancel drücken kann.

Als weitere Stufe:
Wenn dein User über WLAN arbeitet unbd die Verbinding ist weg, kann für kurze Zeit nicht arbeiten. Wie würdest du es da machen?

Verstehe mich nicht falsch, ich möchte gerne EF benutzen, aber ich denke du kommst ohne die DTO und ADO.Net nicht aus!

MfG GIGGS

3.003 Beiträge seit 2006
vor 14 Jahren

Für ein Projekt wär's schon zuviel Aufwand. Im wesentlichen haben wir den Ansatz, den auch deine Extension-Methode SetAllModified() benutzt, gewählt. Das genze mehr oder minder rekursiv über die Referenzeigenschaften, sofern sie gesetzt sind.

Die meisten unserer Services arbeiten RESTful, meist mit XML-Serialisierung. Anhand der in der URI angegebenen Ressource (http://www.beispiel.com/Service/User/ --> User ist die Ressource) und der benutzten Methode des Ansprechens des Dienstes (GET -> Liste, PUT/POST -> Insert/Update, je nach Objekt, DELETE -> entfernen) wird eine der Methoden (skizzenhaft) aufgerufen:


SetRessource<IFlaggable>(IFlaggable ressource);
GetRessource<IFlaggable>(IFlaggable ressource);

IFlaggable ist einfach ein Interface, das alle POCOs implementieren, es fügt ein paar Spezialitäten hinzu (zB die Information darüber, ob's beim Löschen gelöscht oder versteckt werden soll, daher der Name). Den Rest erledigen unsere Bibliotheken und die Definition des Datenmodells. Vorteil ist, dass ich mit Drittanbietern sprechen kann, ohne Verrenkungen zu machen - Stichwort XML-Serialisierung von typisierten Datasets, da krieg ich nur beim dran denken schon Gänsehaut. Vorteil ist eben auch, dass die Objekte in verschiedenen DBMS gespeichert sein können (und auch sind), und ich mir darum nicht die geringste Platte machen muss. Vorteil ist der zwar längst nicht perfekte, aber schon recht gute EDM-Designer im Visual Studio.

Klar eignet sich das nicht für DataBinding in irgendeiner WinForms-Anwendung. tatsächlich sind die Clients, die letzten Endes an unsern Services hängen, aber...öööhm...zu genau null Prozent Windows Forms. Oder WPF. Das sind Java-Desktop-Anwendungen und Javascript-Webclients.

Typisierte Datasets sind toll für ein remoting-basierte Dienste in einer homogenen Umgebung: SQLServer, Windows, Windows Forms. Aber aus so einer homogenen Ecke heraus zu schließen, die ganze Welt wäre mit (typisierten) DataSets gut bedient, ist ein bisschen übers Ziel hinausgeschossen. Wie ich schrieb: das richtige Werkzeug für den richtigen Zweck - trau' niemandem, der dir sagt, dass du nie etwas anderes als XYZ brauchen wirst.

@GIGGS: du gehst bei deinen Fragen von einem DataBinding in einem WindowsForms-Client aus. Hier gibt's keine Massen von Daten, die der User ändern kann, und die dann alle zusammen übertragen werden. Hier gibt's nur einzelne Datensätze. Die WLAN-Frage finde ich auch verwirrend: ich meine, wo ist der Unterschied, ob ich EINEN Datensatz nicht bearbeiten kann, weil ich keine Verbindung hab, oder ob ich ZEHN Datensätze nicht bearbeiten kann? Die Behandlungsmethoden sind in beiden Fällen grundlegend die gleichen - Transaktionen, Puffer, Auslagerung auf Client oder lokalen Service.

Gegenfrage: wie würdest du verhindern, dass alle Ändernugen, die vor dem Speichern vorgenommen wurden, weg sind, wenn der Client abschmiert?

Du siehst - zwei völlig verschiedene Szenarien.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

G
GIGGS Themenstarter:in
67 Beiträge seit 2009
vor 14 Jahren

Hallo,

wieso gibt es keine Massen von Daten, die der User ändern kann?
In meinem Bsp. mit dem Grid ist es doch so!

Man möchte doch , um zu sagen ne halbe stunde daten ändern und dann
bei ok -> SaveChanges(); aufrufen. (Oder halt Cancel)
Erst bei ok, werden die änderungen in der DB gespeichert.

Ich habe es mal in einer reinen lokalen ClientAnwendung so gebastelt und es klappt wunderbar. Ein Datacontext der DB, User ändert 100 verschiedene Datensätze über WPF-Bindings ins ViewModel. Dann bei Button OK eine Zeile -> DB.SaveChanges();
das wars, alles super!

Wenn ich die DB nun nur über nen WCF ansprechen kann, der Client die Daten hat, aber die DB nicht kennt, dann ist es so nicht möglich!

Mit setallmodified() ist der zeitfaktor so groß, da wird man ja ganz GAGA, um den Bezug zur Musik mal zu haben ;o)!!

Mit nem ChangeSet, wo nur die wirklich geänderten Daten / Properties geändert werden müssen, wäre es wohl kein problem.

Verweis:
Chapter 22 "Implementing a smarter WCF Service for Working with Entities"
aus dem Buch "Programming Entity Framework" o'Reilly von Julia Lerman

In diesem Buch werden genau die Probleme beschrieben.
Ich bin der Meinung man kann das im Netz lesen.

MfG GIGGS

365 Beiträge seit 2004
vor 14 Jahren

Hi GIGGS,

wieso gibt es keine Massen von Daten, die der User ändern kann?

Ich verstehe LaTino so, dass es bei ihm keine Massen von Daten gibt. Deswegen gibt es bei ihm die besagten Probleme im Zusammenhang mit dem EF nicht.

Du solltest dir vielleicht doch mal den Weg von Rainbird genauer ansehen. Ich glaube, der ist für dich sinnvoller.

Gruß

Christoph

3.003 Beiträge seit 2006
vor 14 Jahren

Ich verstehe LaTino so, dass es bei ihm keine Massen von Daten gibt. Deswegen gibt es bei ihm die besagten Probleme im Zusammenhang mit dem EF nicht.

Stimmt genau - ich dachte eigentlich, ich hätte mehrmals drauf hingewiesen, wann das eine, und wann das andere sinnvoller ist o_O.

Allein wenn ich DataGrid lese, denk ich schon an DataSets...

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

3.728 Beiträge seit 2005
vor 14 Jahren
Spezialfälle

Für ein Projekt wär's schon zuviel Aufwand. Im wesentlichen haben wir den Ansatz, den auch deine Extension-Methode SetAllModified() benutzt, gewählt. Das genze mehr oder minder rekursiv über die Referenzeigenschaften, sofern sie gesetzt sind.

Das bedeutet, dass Du die für verteilte Anwendungen nötigen Features nachrüstest, indem all Deine Entities eine bestimmte Schnittstelle implementieren. Das gibt aber der Entity-Designer im Standard nicht her, was bedeutet, dass Du die Zusatzfeatures (z.B. RowState) von Hand in jeder Entity-Klasse implementieren musst. Da kann man sich mit Visual Studio-PlugIns, Makros, Code-Generatoren etc. zwar behelfen, aber es ist ein gigantischer Aufwand, wenn man bedenkt, dass typisierte DataSets das alles schon können.

Du hattest in einem vorherigen Post objektorientierte Arbeitsweise als großen Vorteil von EF angeführt. Ein echter objektorientiertet Ansatz, lässt sich per Design in verteilten Anwendungen aber gar nicht verwirklichen, denn eine Grundregel der Objektorientierung sagt "Datenstrukturen und Algorithmen werden in Klassen zusammengefasst und bilden eine Einheit.". Da die Hauptgeschäftslogik (also die Algorithmen) aber in den Services auf dem Server implementiert und damit von den Datenstrukturen (Entities) getrennt sind, wird diese Grundregel von vornherein nicht eingehalten. Im Gegenteil! Bei n-Tier-Anwendungen wird die Logik von den Datenstrukturen getrennt. Man kann also generell nicht von einer objektorientierten Arbeitsweise sprechen. Da auch DataTables und DataSets Klassen sind, die einfach von einer Basisklasse erben, sind diese nicht weniger objektorientiert, als EF-Entities. Und ob man

// DataSet
decimal quantity=orderHeadRow.GetOrderDetailRows()[0].Quantity;

oder

// EF
decimal quantity=order.Details[0].Quantity;

hinschreiben muss, um die Positionsmenge der ersten Position eines Auftrags abzurufen, ist wohl egal. Meinst Du diesen kleinen Unterschied mit "Objektorientierte Arbeitsweise"?

Die meisten unserer Services arbeiten RESTful, meist mit XML-Serialisierung. Anhand der in der URI angegebenen Ressource (
>
--> User ist die Ressource) und der benutzten Methode des Ansprechens des Dienstes (GET -> Liste, PUT/POST -> Insert/Update, je nach Objekt, DELETE -> entfernen) wird eine der Methoden (skizzenhaft) aufgerufen:

Damit kannst Du aber nur CRUD-Operationen abdecken und benötigst wieder für jede einzelne Operation einen Remote-Zugriff. Das ist viel Overhead. Wie bildest Du da Transaktionen?

Vorteil ist, dass ich mit Drittanbietern sprechen kann, ohne Verrenkungen zu machen - Stichwort XML-Serialisierung von typisierten Datasets, da krieg ich nur beim dran denken schon Gänsehaut. Vorteil ist eben auch, dass die Objekte in verschiedenen DBMS gespeichert sein können (und auch sind), und ich mir darum nicht die geringste Platte machen muss. Vorteil ist der zwar längst nicht perfekte, aber schon recht gute EDM-Designer im Visual Studio.

Das ist aber eine spezielle Geschichte. Wenn wir hier über C# reden, gehen wir nicht automatisch davon aus, dass mit anderen Plattformen kommuniziert werden muss. Und da habe ich ganz andere Erfahrungen gemacht. Wenn Du mit Fremdsystemen zu tun hast, sollten Du Deine WCF-Dienste ausschließlich MessageContracts als Parameter annehmen und und auch nur solche zurückgeben. Nur so hast Du wirklich unter Kontrolle, was auf SOAP/REST-Ebene passiert. Man kann böse auf die Nase fallen, wenn man sich da blind auf den DataContractSerializer verlässt.
Was die Datenbankunabhängigkeit angeht, ist das auch eine Spezialsache. Es muss schon einen triftigen Grund geben, warum man eine Anwendung wirklich Datenbankunabhängig macht. Man nimmt dabei den kleinsten gemeinsamen Nenner der unterstützten Datenbanksysteme in Kauf, daran ändert auch EF nichts. Wenn ich z.B. in meinen Objekten GUIDs als Schlüssel verwende (ob das gut ist oder nicht, ist eine andere Diskussion) kann das EF nichts daran ändern, dass MySQL keinen GUID-Datentyp hat. Es bleibt mir dann nichts anderes übrig, als die GUIDs auf dem MySQL als Strings abzubilden. Das ist aber lahm und speicherfressend. In Folge wird die Anwendung Leistungseinbußen haben, wenn sie mit MySQL statt z.B. mit dem Microsoft SQL Server betrieben wird. Wenn ich das vorher weiß, kann ich natürlich auf GUIDs verzichten und in-Schlüssel nehmen, aber kennst Du Dich in allen Datenbanksystemen so gut aus, dass Du im Vorfeld nicht die falschen Entscheidungen triffst. EF macht zwar die SQL-Umsetzung, aber es ist nicht so, dass man sich da keine Platte mehr 'drum scheren muss. Nur wenn Du Dich auf eine bestimmte Umgebung festlegst, wirst Du performante Anwendungen erzeugen. Damit meine ich nicht, dass man sich fest mit einem Datenbanksystem verheiratet, sondern einfach, dass man nicht sagen sollte "Die Datenbank ist egal, der Client ist egal, das Betriebssystem ist egal".

Man sollte sich RDBMS unabhängige Entwicklung nicht aufbürden, nur weil es sich auf der Featureliste der fertigen Anwendung gut macht. Ich will Dir damit nicht unterstellen, dass das bei Dir der Fall ist. Aber wenn dies z.B. in GIGGs Projekt keine Anforderung ist, bringt ihm auch der Vorteil von EF in diesem Bereich nichts. Genauso wenig wie Dir der Vorteil von DataSets beim Windows.Forms-Databinding etwas bringt, wenn Du Java Clients hast.

Klar eignet sich das nicht für DataBinding in irgendeiner WinForms-Anwendung. tatsächlich sind die Clients, die letzten Endes an unsern Services hängen, aber...öööhm...zu genau null Prozent Windows Forms. Oder WPF. Das sind Java-Desktop-Anwendungen und Javascript-Webclients.

Auch das ist eine ganz spezielle Situation. Natürlich hast Du nichts von Vorteilen beim Windows.Forms-Databinding wenn Du kein Windows.Forms einsetzt. Trotzdem hast Du beim Client (ob Java oder sonst was) einiges an Implementierungsaufwand, um Dinge wie RowState in Deiner verteilten Lösung gebacken zu kriegen. Den hättest Du in Deinem Fall natürlich auch bei DataSets, weshalb für Deine spezielle Situation EF wirklich mehr Sinn macht. Du kannst die Vorteile von DataSets in Deiner Umgebung nicht nutzen, aber GIGGS kann es, da er sich scheinbar nicht mit Java- und Javascript-Clients rumärgern muss.

Auch wenn Microsoft das mit WCF oft so propagiert, ist es totaler Unfug, eine Anwendung für eine heterogene Umgebung auszulegen, wenn dafür in einem konkreten Projekt überhaupt kein Bedarf besteht. Warum sollte jemand Daten im XML-Format übers Netzwerk schicken, wenn es binär mindestens fünf Mal schneller geht. Rede mal mit Endanwendern, wie die über Weboberflächen und dauernde Sanduhren fluchen, nur weil es ein temporärer "Modetrend" ist, Anwendungen mit Web-Architektur und Oberflächen im Browser zu entwickeln.

Typisierte Datasets sind toll für ein remoting-basierte Dienste in einer homogenen Umgebung: SQLServer, Windows, Windows Forms. Aber aus so einer homogenen Ecke heraus zu schließen, die ganze Welt wäre mit (typisierten) DataSets gut bedient, ist ein bisschen übers Ziel hinausgeschossen. Wie ich schrieb: das richtige Werkzeug für den richtigen Zweck - trau' niemandem, der dir sagt, dass du nie etwas anderes als XYZ brauchen wirst.

Ob die Bytes mittles Remoting oder WCF übers Netz geschaufelt werden, spielt dabei absolut keine Rolle. Es ist ein Irrtum zu glauben, eine Anwendung müsse auf Internet-Kommunikation ausgerichtet sein, nur weil sie WCF als Kommunikationtechnologie benutzt. Es ist zwar einer per primären Einsatzzwecke von WCF, aber nicht der Einzige. Trotzdem hast Du recht, wenn Du sagst: "das richtige Werkzeug für den richtigen Zweck".

... von einem DataBinding in einem WindowsForms-Client aus. Hier gibt's keine Massen von Daten, die der User ändern kann, und die dann alle zusammen übertragen werden. Hier gibt's nur einzelne Datensätze.

Falsch! Angenommen ein Benutzer soll Verkaufspreise von 4000 Produkten anpassen. Dann macht er nicht jedes Produkt auf und tippt da manuell den neuen Preis ein. Er lässt sich vom Server anhand von Kriterien eine Liste erzeugen. Auf diese Liste wendet er eine Formel an, die alle Preise auf einmal aktualisiert. Vorher wirft er aber vielleicht manuell noch 12 Produkte aus der Liste raus, weil für diese die neue Preise nicht gelten, weil es Spezialartikel sind. Es ist nicht immer so, dass der Benutzer auf Neu Klickt, ein paar Textboxen ausfüllt und dann auf Speichern oder Senden klickt. Leider wird oft davon ausgegangen, dass sich so alle Geschäftsprozesse abbilden lassen.

Gegenfrage: wie würdest du verhindern, dass alle Ändernugen, die vor dem Speichern vorgenommen wurden, weg sind, wenn der Client abschmiert?

Auch wenn die Frage nicht an mich gerichtet war: Wichtig ist, dass das System bei einem Absturz immer konsistent ist, was mit Transaktion erreicht wird. Im Standardfall hätte die Datenbank den Zustand, bevor der Client mit der Bearbeitung begonnen hat. Wenn das in einem konkreten Anwendungsfall nicht zumutbar ist, würde ich in der DB-Tabelle ein Statusfeld einbauen. Der Client kann den Status des Vorgangs dann auf "Unvollständig" setzen und jederzeit speichern, ohne dass Validiert oder Gebucht wird.

3.003 Beiträge seit 2006
vor 14 Jahren

Für ein Projekt wär's schon zuviel Aufwand. Im wesentlichen haben wir den Ansatz, den auch deine Extension-Methode SetAllModified() benutzt, gewählt. Das genze mehr oder minder rekursiv über die Referenzeigenschaften, sofern sie gesetzt sind.
Das bedeutet, dass Du die für verteilte Anwendungen nötigen Features nachrüstest, indem all Deine Entities eine bestimmte Schnittstelle implementieren. Das gibt aber der Entity-Designer im Standard nicht her, was bedeutet, dass Du die Zusatzfeatures (z.B. RowState) von Hand in jeder Entity-Klasse implementieren musst. Da kann man sich mit Visual Studio-PlugIns, Makros, Code-Generatoren etc. zwar behelfen, aber es ist ein gigantischer Aufwand, wenn man bedenkt, dass typisierte DataSets das alles schon können.

Irgendwie liest du da was anderes hinein, als ich geschrieben habe. Unsere Entitäten bleiben so, wie sie der Standarddesigner hinterlaesst - keine partials, kein sonstiger Unfug. Die Entities implementieren keine besondere Schnittstelle. Das habe ich weder implizit noch explizit irgendwo geschrieben oder behauptet. Das Problem, das du hast, ist, dass du glaubst, man müsse unbedingt mit Gewalt einen RowState hineinzwingen, wo der Anwendungsfall keinen erfordert. So stellt es sich mir dar.

Ich kann mit vergleichsweise wenig Aufwand eine Entität an einen neuen Kontext hängen. Es erfordert ein wenig Extra-Arbeit, auch die Relationen abzubilden - das lässt sich über eine Manipulation des ObjextContext erreichen, ohne dass man dafür jede einzelne Entität anfassen müsste. Das ist alles kein Hexenwerk. "Objektorientierte Arbeitsweise" bezog sich darauf, dass Relationen einfach, verständlich, fehlerarm in einem Objektbaum gespeichert werden. Das Ding ist schnell erzeugt, und dem anwendenden Programmierer ist schnurz, wo die Daten herkommen. Wohingegen du für DataSets immer mal wieder eine Extra-Verbeugung machen musst, denn, hey, wir können ALLES. Auch, wenn's gerade keiner braucht 😉.

Im Gegenteil! Bei n-Tier-Anwendungen wird die Logik von den Datenstrukturen getrennt. Man kann also generell nicht von einer objektorientierten Arbeitsweise sprechen.

Das hatten wir schonmal, erinnere ich mich dunkel. Die Argumentation, dass eine Trennung von Daten und Logik keine Objektorientierung mehr ist, kann ich immer noch nicht nachvollziehen. Zumal die Entwicklung seit gut 15 Jahren immer mehr da hingeht, von Experimenten wie ActiveRecord mal abgesehen. Ist meine persönliche Sicht, die nicht unbedingt diskutiert werden muss - ich weiss, dass man das anders sehen kann 😉.

Da auch DataTables und DataSets Klassen sind, die einfach von einer Basisklasse erben, sind diese nicht weniger objektorientiert, als EF-Entities.

Und diese Vererbung von der Basisklasse sind unter Umständen Handschellen, die man lieber nicht hätte. Nicht in jedem Szenario. Offenbar bist du mehr unterwegs in verteilten Anwendungen mit WinForms-Windows-Clients. Damit hab ich nun wieder keine Erfahrung, ich bin in einer Umgebung, in der es genau gar keine WinForms-Anwendungen gibt. Oder WPF. Und ebenso wie du halte ich mein Szenario für das häufiger auftretende - ich denke, darüber muss man nicht streiten 🙂.

Damit kannst Du aber nur CRUD-Operationen abdecken und benötigst wieder für jede einzelne Operation einen Remote-Zugriff. Das ist viel Overhead. Wie bildest Du da Transaktionen?

Über entsprechende Zugriffsketten. Und natürlich kann man mehr als CRUD abbilden - RESTful heisst nicht, dass man sich auf vier Operationen beschränkt. Ich hab's im Beispiel halt kurz gehalten.

Das ist aber eine spezielle Geschichte. Wenn wir hier über C# reden, gehen wir nicht automatisch davon aus, dass mit anderen Plattformen kommuniziert werden muss.

Wie bitte? In einer Welt, in der die .NET-Desktopapplikationen im einstelligen Prozentbereich sind? Hm. Nach meiner Erfahrung darf ich, wenn mein Programm mit einer anderen Software auf irgendeine Weise interagieren soll, NIEMALS davon ausgehen, dass auf der anderen Seite .NET läuft. Ist mir in den letzten 5 Jahren auch nicht passiert. Wir sind Nischenentwickler, wenn man ehrlich ist 😉.

Man kann böse auf die Nase fallen, wenn man sich da blind auf den DataContractSerializer verlässt.
Was die Datenbankunabhängigkeit angeht, ist das auch eine Spezialsache. Es muss schon einen triftigen Grund geben, warum man eine Anwendung wirklich Datenbankunabhängig macht. Man nimmt dabei den kleinsten gemeinsamen Nenner der unterstützten Datenbanksysteme in Kauf, daran ändert auch EF nichts. Wenn ich z.B. in meinen Objekten GUIDs als Schlüssel verwende (ob das gut ist oder nicht, ist eine andere Diskussion) kann das EF nichts daran ändern, dass MySQL keinen GUID-Datentyp hat. Es bleibt mir dann nichts anderes übrig, als die GUIDs auf dem MySQL als Strings abzubilden.

Guids als String? Wieso denn sowas? Ich mein - die Modelle sind nix Starres, die darf man zur Laufzeit ruhig ändern.

DataContractSerializer ist wie...hm, keine Ahnung. Eins dieser Out-of-the-Box-Spielsachen halt. Funktioniert, solang man sich an die Regeln hält, und wenn man mal was Spezielleres machen will, ist man sowieso auf eigene Lösungen angewiesen, die, wie sich dann später herausstellt, sowieso flexibler, schneller und sauberer sind. Das .net-Framework wimmelt von solchen Sachen.

Aber deine ganze Argumentation mit MySql...du hast noch nicht allzuviel mit verschiedenen DBMS gemacht, oder? Das ist hanebüchen, ehrlich.

Für GIGGS sind in seinem Szenario die DataSets vermutlich 'ne bessere Lösung. Hab ich ja nun hinreichend oft geschrieben. Nur, deine Argumentation, dass für verteilte Systeme nur DataSets in Betracht kommen, ist schon stark von deinem eigenen Erleben geprägt.

Für den Sonderfall, in dem du arbeitest, wo du alles unter Kontrolle hast, eine homogene Infrastruktur UND Einfluss auf die Clients - ja, gerne. Aber wenn die Infrastruktur NICHT vorhanden oder nicht homogen vorhanden ist, dann dennoch auf DataSets zu bauen und hoffen, dass die hohen Infrastrukturkosten durch lange Laufzeit der Software schon irgendwann ammortisiert werden...nee. Werden sie nicht. Klar halten Konzepte wie EF nicht alles, was versprochen wird. Aber sie sind tatsächlich flexibler, schneller einsetzbar, und vor allem schneller auf vorhandene Szenarien anpassbar. Was das betrifft, sind DataSets unglaublich fett und unbeweglich.

Auch wenn Microsoft das mit WCF oft so propagiert, ist es totaler Unfug, eine Anwendung für eine heterogene Umgebung auszulegen, wenn dafür in einem konkreten Projekt überhaupt kein Bedarf besteht.

Wann ist eine Infrastruktur mal NICHT heterogen? Klar, in einem solchen Fall ist es tatsächlich Unfug. Schlimmer ist aber, eine für homogene Infrastrukturen gedachte Software zu schreiben und über eine heterogene Infrastruktur stülpen zu wollen.

Gegenfrage: wie würdest du verhindern, dass alle Ändernugen, die vor dem Speichern vorgenommen wurden, weg sind, wenn der Client abschmiert?
Auch wenn die Frage nicht an mich gerichtet war: Wichtig ist, dass das System bei einem Absturz immer konsistent ist, was mit Transaktion erreicht wird. Im Standardfall hätte die Datenbank den Zustand, bevor der Client mit der Bearbeitung begonnen hat. Wenn das in einem konkreten Anwendungsfall nicht zumutbar ist, würde ich in der DB-Tabelle ein Statusfeld einbauen. Der Client kann den Status des Vorgangs dann auf "Unvollständig" setzen und jederzeit speichern, ohne dass Validiert oder Gebucht wird.

Mit anderen Worten: wenn (durch den Nutzer) getätigte Aktionen nicht verloren gehen dürfen, weichst du lieber dein propagiertes Konzept auf, statt umzuorientieren? Richtiges Werkzeug und so 😉 (Hint: Transaktionsproxy)

Mag sein, dass ich mich täusche. Aber die Zahlen zur Verbreitung von .net-Desktopapplikationen sind, glaube ich, eher auf meiner Seite 😁

Falls hier paar Sachen etwas zu hart rüberkommen, entschuldige das bitte. Ich bin nicht gerade geborener Diplomat^^

@GIGGS: vorhin gefunden, sind hier ein paar richtig gute Tipps für den Umgang mit EF. Auch wenn DataSets in deinem Fall wie gesagt die bessere Wahl sein dürften, die Beschäftigung mit EF ist auf keinen Fall Zeitverschwendung 🙂.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

F
10.010 Beiträge seit 2004
vor 14 Jahren

Mag sein, dass ich mich täusche. Aber die Zahlen zur Verbreitung von .net-Desktopapplikationen sind, glaube ich, eher auf meiner Seite großes Grinsen

Wie kommst Du da drauf?

3.003 Beiträge seit 2006
vor 14 Jahren

*sigh* das hatte ich befürchtet 😉 Vor einiger Zeit war (auf heise?) eine schicke Tabelle mit 'ner Analyse, womit wie viele Desktop-Applikationen geschrieben werden. C++/MFC war mit großem Abstand oben, auch noch Delphi, dann ein nicht unbedeutender Anteil Java, etwas TCL, qt, den Rest teilten sich .NET/Flex/(wx)Python und Konsorten. Ich kann nicht versprechen, dass ich das wiederfinde, aber ich such mal. Hat sich aber eingebrannt, weil ich doch überrascht/enttäuscht war.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

3.003 Beiträge seit 2006
vor 14 Jahren

Auf die Schnelle nur den TIOBE-Index gefunden. Wie alle Statistiken gilt auch hier - nur dem trauen, was man selber gefälscht hat. Da sich das aber mit dem deckt, was ich "draussen" beim Kunden so erlebe, bin ich geneigt, eine ähnliche Verteilung auch für Desktopapplikationen anzunehmen. Mit geringerem Anteil Java, höherem Anteil ABAP / Delphi / C++, würde ich vermuten. Laesst man VBA auch als echte Anwendungen zählen, verschiebt sich das ganze sicherlich in diese Richtung. Aber wie man es dreht und wendet - C#/.NET ist relevant, aber nicht dominierend.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

3.728 Beiträge seit 2005
vor 14 Jahren

"Objektorientierte Arbeitsweise" bezog sich darauf, dass Relationen einfach, verständlich, fehlerarm in einem Objektbaum gespeichert werden. Das Ding ist schnell erzeugt, und dem anwendenden Programmierer ist schnurz, wo die Daten herkommen. Wohingegen du für DataSets immer mal wieder eine Extra-Verbeugung machen musst, denn, hey, wir können ALLES. Auch, wenn's gerade keiner braucht 😉.

Es ist bei Beiden Technologien das Selbe Konzept: Man klickt die Struktur in einem Designer zusammen, der Code (Klassen) erzeugt. DataSets sind absolut unabhängig von der Datenquelle. Der einzige Unterschied ist, dass typisierte DataSets auf einem generischen Datencontainer aufgebaut sind, der flexibel ist. Aber wo muss man eine Verbeugung machen, um ein DataSet zu befüllen?

Und diese Vererbung von der Basisklasse sind unter Umständen Handschellen, die man lieber nicht hätte. Nicht in jedem Szenario. Offenbar bist du mehr unterwegs in verteilten Anwendungen mit WinForms-Windows-Clients.

Ja, definitiv. Ich habe wiederum mit Web-Sachen nichts am Hut.

Damit hab ich nun wieder keine Erfahrung, ich bin in einer Umgebung, in der es genau gar keine WinForms-Anwendungen gibt. Oder WPF. Und ebenso wie du halte ich mein Szenario für das häufiger auftretende - ich denke, darüber muss man nicht streiten 😃.

Da hast Du Recht, darüber muss man wirklich nicht streiten, das sind einfach verschiedene Welten.

Wie bitte? In einer Welt, in der die .NET-Desktopapplikationen im einstelligen Prozentbereich sind?

Woher hast Du diese Zahl?
Das mag vielleicht bei Software so sein, die als kommerzielles Produkt verkauft wird, aber der überwiegende Prozentsatz an .NET-Code sind doch individuelle Sachen, Projekte. Darüber gibt es gar keine aussagekräftige Statistik. Die Anwender wollen den Komfort, den sie von Office & Co. gewohnt sind auch in den Geschäftsanwendungen haben. Das ist mit ASP.NET nicht drin. Denk' nur mal an die ganzen Visual Basic 6-Umsteiger, die Umsteiger von Delphi und FoxPro und alle die Erweiterungen für Office (Stichwort VSTO) entwickeln. Die machen nicht alle plötzlich Web.

Nach meiner Erfahrung darf ich, wenn mein Programm mit einer anderen Software auf irgendeine Weise interagieren soll, NIEMALS davon ausgehen, dass auf der anderen Seite .NET läuft. Ist mir in den letzten 5 Jahren auch nicht passiert. Wir sind Nischenentwickler, wenn man ehrlich ist 😉.

Dabei nützen Dir Webservices und modernes WCF-Geplänkel aber auch nix. Wie sieht denn EAI in der Praxis aus? Text-Files, EDIFACT-Nachrichten und wenn es hochkommt XML-Schnittstellen. Mit Methodenaufrufen via SOAP/REST ist nicht viel. Das kommt erst langsam. Deine REST-Schnittstellen bringen Dir nix, wenn die andere Anwendung plötzlich z.B. XML-RPC macht, weil deren Entwickler das mal cool fand. Deshalb brauchst Du auf Fremdapplikationen gar keine Rücksicht zu nehmen, denn es wird meistens eh nicht passen. Wichtig ist dass Deine Anwendung in Komponenten aufgeteilt ist, die automatisierbar sind und man Daten in definierten Formaten rein und raus bekommt. Die Kommunikation zwischen den heterogenen Anwendungen überlässt Du dann lieber einem Tool wie dem Microsoft BizTalk Server. Der sorgt für das Mapping der Daten und liefert die nötigen Adapter, um die verschiedenen Welten an seinen Bus anzukoppeln. Das ist dann besonders effektiv, wenn man nicht nur zwei Anwendungen sondern n Anwendungen miteinander verdrahten muss. Und das ist meistens der Fall. So ist z.B. der Webshop in PHP, das ERP-System in .NET und die Software des Versanddienstleisters in Sonstwas implementiert. Wenn ich meine ERP-Software, auf die ich Einfluss habe nun voll an W3C-Standards wie SOAP oder REST ausgerichtet habe, wird die Integration der drei Anwendungen am Ende kein bisschen einfacher oder besser, denn der PHP-Webshop hat vielleicht eine dreckige HTML-Form-Post-Schnittstelle und das Versandprogramm akzeptiert nur CSV-Dateien.

Die Vorstellung, dass alle sich brav an die Standards halten und man die Services der einzelnen Anwendungen nur noch kurz zu einem "Zusammenkonfigurieren" kann, ist Utopie. Wichtig ist, dass man überhaupt Schnittstellen hat und einfache Möglichkeiten für den Datenaustausch mit anderen Anwendungen einbaut. Die Integration in einen übergeordneten EDV gestützten Geschäftsprozess ist eh ein separates Projekt. Ob bei der in den Ordner eingestellten Textdatei über den FileSystemWaqtcher nun ein WCF-Service über SOAP und Zertifikatsauthentifizierung oder eine sink properitäre Remoting-Komponente über einen TcpChannel mit Windows-Auth. aufgerufen wird, ist exakt der Selber Aufwand. In beiden Fällen muss ich den Code dafür im Rahmen des entsprechenden EAI-Projekts schreiben oder eine BizTalk-Orchestration und die Port-Konfiguration dazu anlegen.

Die Vorteile in heterogenen System werden überbewertet. Und die Kommunikation zwischen Unternehmen? Meistens ist man froh, wenn man halbwegs strukturierte Excel-Tabellen von Geschäftspartnern bekommt, die man dann mühsam parsen darf. Selbst Anbieter von e-Procurement Marktplätzen halten sich selten an gängige Standards wie z.B. das BMECat-Format und bauen einfach eigene XML-Tags ein und solche Scherze.
Auch die Kommunikation mit Behörden ist alles andere als Standardisiert. Der Zoll z.B. verwendet das alte X.400-Mailsystem um EDIFACT-Nachrichten auszutauschen. Die Bundensfinanzbehörde bietet XML-RPC-Schnittstellen an, um Umsatzsteueridentnummern zu prüfen. An anderen Stellen wird man auf eine Webseite verweisen, die man dann von Hand im Browser bedienen darf. Jeder kocht sein eigenes Süppchen. Ich habe jede Menge Erfahrung mit heterogenen Umgebungen.

Guids als String? Wieso denn sowas? Ich mein - die Modelle sind nix Starres, die darf man zur Laufzeit ruhig ändern. Wie würdest Du das Modell in diesem Fall denn ändern? Die Umstellung auf int-Autowerte würde die komplette Architektur verändern, da dann plötzlich Clients keine gültigen Schlüssel mehr erzeugen könnten.

DataContractSerializer ist wie...hm, keine Ahnung. Eins dieser Out-of-the-Box-Spielsachen halt. Funktioniert, solang man sich an die Regeln hält, und wenn man mal was Spezielleres machen will, ist man sowieso auf eigene Lösungen angewiesen, die, wie sich dann später herausstellt, sowieso flexibler, schneller und sauberer sind. Das .net-Framework wimmelt von solchen Sachen.

Wenn Die bequemen Standardspielsachen aber eh nichts taugen, wenn es ernst wird, dann kannst Du auch DataSets verwenden und ggf. auftretende Kompatibilitätsprobleme mit Fremdsystemen mit MessageContracts in den Services abfackeln. Die eigentliche Geschäftslogik sollte eh nicht direkt in den WCF-Services implementiert werden, da man sie sonst ungewollt mit dem Kommunikations-System verheiratet.

Aber deine ganze Argumentation mit MySql...du hast noch nicht allzuviel mit verschiedenen DBMS gemacht, oder? Das ist hanebüchen, ehrlich.

Ich habe schon mit folgenden RDBMS gearbeitet: MSSQL, MySQL, Sybase, Access. Das sollte reichen, um mitreden zu können.

Nur, deine Argumentation, dass für verteilte Systeme nur DataSets in Betracht kommen, ist schon stark von deinem eigenen Erleben geprägt.

Auch DataSets sind nicht der heilige Gral. Wenn man z.B. wie Du Java Clients hat, die mit dem übertragenen DataSet-XML nicht viel anfangen können (weil eine Deserialisierung in entsprechende Java-Objekte schwierig ist) wäre DataSets sogar kompletter Unfug. Da muss ich allerdings hinterfragen, warum man die Geschäftslogik in .NET implementiert, obwohl sicher ist, dass die Clients Java-Desktopapplikationen under JavaScripts sind? Mit Glassfish oder Tomcat lässt sich das doch genauso leicht in Java machen. Warum eine Anwendung mit unterschiedlichen Technologien erstellen, wenn man alles mit einer Technologie machen kann? Die NetBeans IDE von Sun hat genauso viele Designer für jeden Piep wie Visual Studio (Mit Eclipse kenn ich mich nicht aus, da geht das aber bestimmt auch easy, wenn man die passenden Plug-Ins installiert hat). Wo liegt die Motivation innerhalb einer Anwendung/eines Projekts die komplette Plattform zu wechseln? Es gibt bestimmt einen guten Grund dafür, aber der liegt nicht klar auf der Hand.

Für den Sonderfall, in dem du arbeitest, wo du alles unter Kontrolle hast, eine homogene Infrastruktur UND Einfluss auf die Clients - ja, gerne. Aber wenn die Infrastruktur NICHT vorhanden oder nicht homogen vorhanden ist, dann dennoch auf DataSets zu bauen und hoffen, dass die hohen Infrastrukturkosten durch lange Laufzeit der Software schon irgendwann ammortisiert werden...nee. Werden sie nicht. Klar halten Konzepte wie EF nicht alles, was versprochen wird. Aber sie sind tatsächlich flexibler, schneller einsetzbar, und vor allem schneller auf vorhandene Szenarien anpassbar. Was das betrifft, sind DataSets unglaublich fett und unbeweglich.

Welche Infrastruktur ist nicht vorhanden? Ich habe nicht gesagt, dass ich DataSets verwenden würde, wenn die Clients nicht in .NET erstellt sind. Wenn Du auf den Client eh keinen Einfluss hast, kommt es darauf an, ob Du Dich nach den Client-Herstellern richten musst, oder umgekehrt. Wenn die Vorgabe ist, dass die Clients über REST mit XML kommunizieren, müssen DataSets nicht verkehrt sein. Die werden in einwandfreies XML serialisiert. Schema gibt's auch dazu. Jedes Client-System, welches auf eine DOM-Implementierung zurückgreifen kann, hat so die Möglichkeit mittels W3C-Standards mit den Daten zu arbeiten. Das DataSet-Schema ist leicht verständlich.
Aber wo habe ich höhere Infrastrukturkosten, wenn ich DataSets als DTOs einsetze? Hä?! Das verstehe ich nicht. Einen Windows-Server muss ich sowohl bei EF als auch bei DataSets am laufen haben. Egal ob Objekte oder DataSets, bei Beiden kommt beim Client XML an. Bei DataSets habe ich weniger Möglichkeiten, die Form dieses XML-Codes zu beeinflussen. Das ist in heterogenen Systemen ein großer Nachteil. Aber was hat das mit Infrastrukturkosten zu tun?

Wann ist eine Infrastruktur mal NICHT heterogen? Klar, in einem solchen Fall ist es tatsächlich Unfug. Schlimmer ist aber, eine für homogene Infrastrukturen gedachte Software zu schreiben und über eine heterogene Infrastruktur stülpen zu wollen.

Die gesamte IT-Infrastruktur eines Unternehmens ist fast immer heterogen (Siehe mein Beispiel von oben). Aber auf der Ebene werden keine Anwendungen entworfen. Es ist ja immer ein Zusammenspiel von eigenem Code und Fremdapplikationen. Jede Anwendung für sich lebt ihn ihrer Abgeschlossenen Welt und Umgebung. Über Schnittstellen kommuniziert eine Anwendung mit der Außenwelt. Wie diese Außenwelt aussieht, muss die einzelne Anwendung nicht kümmern, es sei den es ist selber eine Anwendung für EAI-Infrastruktur.

Mit anderen Worten: wenn (durch den Nutzer) getätigte Aktionen nicht verloren gehen dürfen, weichst du lieber dein propagiertes Konzept auf, statt umzuorientieren? Richtiges Werkzeug und so 😉 (Hint: Transaktionsproxy)

Wenn ich das Konzept des Transaktionsproxy gekannt hätte, wäre ich vielleicht darauf ausgewichen. Hab damit leider noch keine Erfahrung und muss erst nachlesen, was es damit auf sich hat. Danke für den Hint.

Mag sein, dass ich mich täusche. Aber die Zahlen zur Verbreitung von .net-Desktopapplikationen sind, glaube ich, eher auf meiner Seite 😄

Da solltest Du Dich nicht so sicher fühlen. Die Windows-Oberflächenfraktion ist größer, als Du denkst.

Falls hier paar Sachen etwas zu hart rüberkommen, entschuldige das bitte. Ich bin nicht gerade geborener Diplomat^^

Das ist schon okay.

3.728 Beiträge seit 2005
vor 14 Jahren
Neues .NET

Natürlich nicht. .NET gibt es ja erst seit 2001. Seit 2005 sind erst die groben Kinderkrankheiten beseitigt. Sowas dauert. Java hat nicht viel mehr und das gibt es immerhin schon seit 1995.

Die ganzen Firmen schmeißen nicht einfach ihren C++ oder Delphi-Code weg, nur weil C# jetzt gerade modern ist.

Deshalb halte ich die momentane Technologie-Schwämme im .NET-Bereich für sehr schädlich. Keine Firma kann alle zwei Jahre auf andere Technologien wechseln. Heute Remoting, morgen WCF. Die WF 3.5 wird komplett geklickt und neu aufgestellt. Wenn man heute in eine Technologie investiert, ist sie morgen vielleicht schon auf dem Abstellgleis. Manche denken so über die komplette .NET Plattform. Fast kein großes Microsoft-Produkt besteht vorwiegend aus .NET Code. Der BizTalk-Server noch am ehesten. Der ist aber Infrastruktur. Office ist weiterhin COM. Die Makrosprache von Office ist weiterhin VBA. Auch in Windows 7 ist nicht viel .Nettiges zu sehen.

Trotzdem ist .NET zukunftsträchtig.