Hi,
ich bin dabei ein Repository Pattern für den Datenzugriff zu implementieren und suche nach einer guten Lösung für das Caching der Daten im Speicher. Ich will dabei ungern das Rad neu erfinden und meinen eigenen Cache implementieren ...
Wozu ratet ihr?
FZelle, nach deiner Erklärung kann ich das ganze dann so beschreiben:
Ich habe einen TimeService und einen PlayerStateProvider sowie einen PlayerStateService. Nun hängt der PlayerStateProvider vom TimeService ab.
Dann ist die Frage: Ist es sinnvoll, dass ein Provider von einem Service abhängt? Oder sollte diese Abhängigkeit von einem Service gekapselt werden?
Warum die Unterscheidung zwischen PlayerStateService und PlayerStateProvider?
Weil der PlayerStateService Konsumerorientiert und Stateless ist, im Gegensatz zum PlayerStateProvider
Ich sehe aktuell auch keine Probleme in meinem Design, ich interessiere mich nur für Konzepte und Good Practice.
Den Äußeren Server will ich halt vermeiden, da der Provider darauf angewiesen ist, dass er regelmäßig den Zustand prüft. Dieses Wissen sollte ein Service, der den Provider nutzt nicht haben.
Die Provider hängen alle über Interfaces zusammen. Aktuell ist alles überschaubar und ich verbinde es direkt im Code ohne extra DI Container. Aber das lässt sich bei bedarf nachrüsten.
Ich hab schon einiges über SOA gehört und gelernt, das meiste bezieht sich auf Services. Jetzt habe ich mehrere Provider die von anderen Providern abhängen.
Beispiel:
Ein TimeProvider gibt die aktuelle Zeit
Ein PlayerStateProvider nutzt intern jede Sekunde den TimeProvider, um festzuhalten, wann sich der Zustand des Spielers geändert hat.
Aktuell hängt der PlayerStateProvider (und andere Provider) direkt vom TimeProvider ab.
Ist das nun schlechtes Design? Und warum?
Wenn ich dass in einem Service implementieren würde, müsse der Service:
Von PlayerStateProvider und TimeProvider abhängen und den PlayerStateProvider regelmäßig aktiv nach dem Zustand des Spielers fragen. Denn wird der PlayerStateProvider mal nicht gefragt, bekommt er die Zeit, wann sich der Zustand geändert hat nicht mit.
Wie designe ich das ganze am besten Serviceorientiert?
Ich verwende den Updater immer gerne, ich weiß nicht wie es Zeitlich klappt - Grundsätzlich hätte ich aber schon Interesse Erweiterungen dafür zu schreiben.
Wir sind mit dem Projekt sehr weit voran gekommen. Der Bau hat die nötigen Landschaften und Gebäude für den Livebetrieb fertig gestellt, die Fangemeinde ist seit der ersten Anfrage hier stetig gewachsen.
Es gibt ein Liveserver auf dem Bereits Betatests mit Spielern durchgeführt wurden und bis Spielstart weitere Tests folgen.
Man kann sagen, wir befinden uns in den letzten Zügen vor Spielbeginn. Wir such dennoch weiterhin fähige Programmierer, die sich für unser Projekt begeistern lassen.
Wenn ihr also Interesse oder Fragen habt meldet euch gerne bei mir.
Gruß, Tarion
Ich habe selbst wenig Erfahrungen, vor Kurzem habe ich aber von einem Kollegen der sich tiefgehender mit dem Thema beschäftigt hat das für spezielle Anwendungen das Event nicht mehr ausreicht. Aber angeblich sind ihm durch die Events in bestimmten fällen daten verloren gegangen oder in der falschen Reihenfolge angekommen. Das hängt aber auch von der Peripherie ab, wie USB/Seriell Wandler, etc. und ist kein reines C# Problem gewesen.
Es gibt 2 Bedingungen damit das Event gefeuert wird.
- eine konfigurierte Anzahl Bytes wurde empfangen
- es sind Daten vorhanden und eine konfigurierte Zeit ist vergangen
Diese beiden Werte können in der SerialPort Klasse eingestellt werden. Paramternamen habe ich nicht im Kopf.
In Zeitkritischen Anwendungen und in Multithreadanwendungen kann dieses Verhalten durchaus Probleme verursachen. In den meisten Anwendungen wird es aber ausreichen.
Der sicherste Weg wäre ein eigener Thread der auf neue Daten pollt. Dann hat man alles was ankommt und in welchen Threads es verarbeitet wird selbst in der Hand.
Das stimmt so nicht: Wenn der Member, der den Delegate "erwartet"
publicist, muss auch der Delegat öffentlich zugänglich sein.
Und wenn der Member z.B.internalist, macht die Sichtbarkeit des Delegaten keinerlei Unterschied.
Hm ja, ich dachte an so etwas wie unten gezeigt. Aber da macht es dann tatsächlich keinen Unterschied ob das Delegate internal ist oder nicht.
internal delegate void FilterFunc();
public class ImplementingFilter
{
private FilterFunc m_MyFilter;
internal FilterFunc MyFilter
{
get { return m_MyFilter; }
set { m_MyFilter = value; }
}
public ImplementingFilter()
{
}
public void FilterSomething()
{
m_MyFilter.Invoke();
}
}
Du hast für deine Definitionen zwei Möglichkeiten:
(1) Zur Laufzeit Interpretieren oder (2) in C# Code umwandeln. Mir fallen grad nicht mehr ein.
(1) Du kannst dir die Struktur der erwarteten Daten anlegen und dem Message Reader zur Verfügung stellen. Die Definition dient dann quasi als Konfiguration für den Parser der die Daten strukturiert ablegt. Die geparsten Daten können z.B. in Dynamics abgelegt werden. Dies kostet allerdings etwas Typsicherheit.
(2) Ist im Prinzip dein Vorschlag. Du kannst per CodeDOM Code erzeugen, Compilieren, Einbinden und per Reflection drauf zugreifen. Hier bist du Typsicher.
Was nun mehr Arbeit macht ist die Frage. Ich denke ich würde einen unabhängigen Codegenerator für (2) bauen und die Klassen dann statisch einbinden und im Programm nutzen.
(3) Du kannst natürlich die gegebenen Definitionen auch per Hand in Code übersetzten.
Schau dir mal WCF an, die definieren auch Protokolle und erzeugen auf Basis der Metainformationen die Datenstrukturen - in dem Fall Interfaces.
Gruß.