Zurzeit entwickle ich gerade eine Win Forms Clientanwendung die mit einer bestehenden (auf PHP basierenden) Webanwendung zusammenarbeiten soll.
Nun bietet mir .NET die Möglichkeit solche ClientFormsAuthenticationMembershipProvider zu verwenden, welche ja von der abstrakten MembershipProvider Klasse erben, um eine bestehende Benutzerauthentifizierung zu verwenden. Dazu müsste aber bei diesen Provider eine bestehende ASP.NET Site mit Membership-Funktionalität vorhanden sein, da die eigenliche Verbindung zur Datenquelle immer noch auf Serverseite vorgenommen.
Da ich aber auf Serverseite nur einen Webspace mit PHP, MySQL und PgSQL zur Verfügung habe, dachte ich mir ich implementiere selber solchigen Provider.
Nun sind mir dazu mehre Ansätze eingefallen.
- Ich setze auf Serverseite ein Script auf, welches Daten von dern Clientanwendung per JSON, SOAP or whatever, entgegennimmt und eine entsprechende Daten zurückschickt. Verbindungsweg HTTP.
So würde es auch der ClientFormsAuthenticationMembershipProvider im .NET Framework machen, Daten per JSON an einen ASP-Webdienst senden, soweit ich das verstanden habe. - Ich kommuniezier direkt mit dem MySQL oder PgSQL Server über die entsprechenden Connectoren für .NET und erhalte somit meine Daten direkt und ohne Umwege. Diese Möglichkeit besteht nur, wenn mir Zugriff von Extern auf den DB-Server gestattet wird.
Ich werde ja in diesem Proekt ausgiebig mit LINQ arbeiten, muss ich mir sowieso DAO-Klassen erstellen, welche mir im Endeffekt als Objekt 1:1 eine Tabelle abbildet, smit kann ich dann einfach mit LINQ to Objects arbeiten. Es gäbe zwar im VS einen Object Relational Designer (O/R-Designer) welche im Endeffekt das selbe macht was ich machen würde, eine 1:1 Abbildung einer SQL-Tabelle, halt nur mit praktischer Designer Oberfläche. Diese arbeitet aber leider nur mit dem MS-SQL Server zusammen. Und meine Daten können aus allen möglich Datenquellen stammen.
- Entweder ich arbeite in meiner Implementierung der ClientFormsAuthenticationMembershipProvider direkt mit den Methoden der MySQL oder PgSQL Connector-Klassen.
- Oder ich bleibe bei meinen Ansatz und werwende in der Provider Klasse rein LINQ to Objects abfragen auf meine eh schon als Objekte abgebildeten Tabellen und behalte so meine Flexibilität und Unabhängigkeit von den Datenquellen, welche sich ja unter Umständen ändern können.
Dann gäbe sich mir noch eine Frage an die Dateistrukturierung der Clientanwendung.
- Soll ich die DAO-Klassen direkt ins Projekt einbinden oder in der Projektmappe jeweils Projekte dazu erstellen?
- Falls eigene Projekte in einer gemeinsamen Proektmappe, soll ich die Projekte nach Art der Datenquelle organisieren oder nach Art dessen was sie abbilden.
- Wenn ich dann die einzelnen Projekte als .dll in die Hauptanwendung (diese enthält dann auch das DAO-Konstrukt, oder soll ich dieses auch lieber in eine extrige .dll auslagern?) linke, soll ich die .dll's lieber in die .exe einkompilieren oder als extrige Dateien mitliefern. bei zweiteren könnte ich die Art der Datenquelle leichter austauschen ohne alles extrig mitliefern zu müssen.