Autor |
Beitrag |
Talemantros
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Mo 28.04.14 16:47
Hallo,
ich möchte gern eine PinAbfrage in meine Applikation einbauen.
Dies soll so aussehen, dass immer wenn eine wichtige Tätigkeit ansteht (zum Beispiel Speichern) soll sich eine neue WinForm öffnen, die eine Pin Abfragt.
Aus dieser Pin resultiert aus einer Methode der Mitarbeitername, der diese Aktion versucht auszuführen.
Nun möchte ich, dass der Name und die Pin in dem Usercontrol der Form wo auf Speichern gedrückt wurde vorhanden ist um diesen weiter zu verarbeiten.
Vermutlich reden wir hier wieder von Events etc.!?
Wie müsste ich da ran gehen?
Danke
Gruß
EDIT: Habe hierzu noch mal das Beispielprogramm von TH69 www.bitel.net/dghm11...ion_von_2_Forms.html zu rate gezogen und versuche das für meine Zwecke zu nutzen
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Di 06.05.14 16:09
Hallo,
wie oben geschildert möchte ich bei bestimmten Aktionen in meiner Software abfragen, ob der Mitarbeiter dies darf oder nicht.
Dazu wollte ich eine Form anzeigen lassen, die eine Pin abfrage und nach einigen Kriterien darf der Mitarbeiter dies dann oder halt nicht.
Den Namen des Mitarbeiters benötige ich dann in der Grundform, wo er die Aktion tätigen wollte.
Nun habe ich mir dazu o.g. Projekt von TH69 heruntergeladen um die Kommunikation zwischen 2 Forms zu verstehen.
Da mir Copy & Paste nicht liegt und ich gerne verstehe was ich da tue, hätte ich da mal eine Frage zu folgendem Code.
C#-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| protected void OnUpdateText(string text) { OnUpdateText(new TextEventArgs(text)); }
protected virtual void OnUpdateText(TextEventArgs e) { EventHandler<TextEventArgs> ev = UpdateText; if (ev != null) ev(this, e); } |
Mir ist an dieser Stelle nicht ganz klar, warum ich 2 Methoden brauche mit demselben Namen und für was das virtual steht bzw was die einzelnen Methoden für sich da welche Aufgabe übernehmen.
Kann jemand versuchen mir das näher zu bringen?
Danke
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Di 06.05.14 16:51
Bezüglich virtual hilft denke ich am besten ein Blick in die MSDN Hilfe. Ich könnte eh nur wiederholen was da schon steht und vermutlich auch nicht besser.
Und brauchen tust du die beiden Methoden nicht genauso wenig wie das virtual hier jetzt gerade zwingend wäre oder die Methoden protected zu machen. Ein OnEvent zu haben um einen Event zu feuern ist aber der übliche Best Practise Ansatz. Gerade wenn man es richtig macht und vor dem Aufrufen den EventHandler kopiert und dann den Event über die Kopie feuert so wie im gezeigten Code. Mitten im Code einfach ein
C#-Quelltext 1: 2:
| if(UpdateText != null) UpdateText(this, new TextEventArgs("MeinLieberText")); |
anstatt einer der beiden Methodenaufrufe ginge aber auch.
|
|
Th69
      

Beiträge: 4798
Erhaltene Danke: 1059
Win10
C#, C++ (VS 2017/19/22)
|
Verfasst: Di 06.05.14 17:12
Hallo Talemantros,
die erste Methode ist nur eine sog. "Convenience"-Methode, d.h. um Schreibarbeit beim Aufruf zu sparen.
Und die zweite ist, wie Ralf ja schon schrieb, der übliche Weg, um Events auszulösen (s.a. Event Design sowie How to: Raise Base Class Events in Derived Classes). Aber thread-safe, im Gegensatz zu dem von Ralf beschriebenen Aufruf (durch Anlegen einer lokalen Variable)!
Mittels einer Erweiterungsmethode (in einer eigenen statischen Klasse) läßt sich das sogar noch weiter verkürzen:
C#-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16:
| public static void RaiseEvent<T>(this EventHandler<T> eventHandler, object sender, T e) where T : EventArgs { if (eventHandler != null) { eventHandler(sender, e); } } |
Der Aufruf verkürzt sich dann zu
C#-Quelltext 1:
| UpdateText.RaiseEvent(this, new TextEventArgs("MeinLieberText")); |
(ohne also selber explizit auf null abprüfen zu müssen!)
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Di 06.05.14 17:26
Ich glaube der Kommentar an der Extension Method ist gelogen
So kurze statische Methoden werden fast garantiert geinlined und es wird keine Methodenaufruf passieren der eine Kopie anlegt.
Insofern sollte in der Methode immer noch der Handler explizit kopiert werden da man sich nicht sicher sein kann das da bereits automatisch kopiert wurde.
Oder gibt es bei Extension Method da eine Sonderbehandlung vom Compiler die ich nicht kenne?
Edit : Gerade ausprobiert und die Extension Method ist nicht im StackTrace, wurde also geinlined und this nicht kopiert.
Quelltext 1: 2: 3:
| at ConsoleApplication15.Program.Handler(Object sender, EventArgs e) at ConsoleApplication15.Program.Main(String[] args) Drücken Sie eine beliebige Taste . . . |
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34:
| class Program { static void Main(string[] args) { var tmp = new EventRaiser(); tmp.Event += Handler; tmp.ThrowEvent(new object()); }
static void Handler(object sender, EventArgs e) { Console.WriteLine(new StackTrace().ToString()); } }
public class EventRaiser { public EventHandler<EventArgs> Event;
public void ThrowEvent(object sender) { Event.RaiseEvent(sender, EventArgs.Empty); } }
public static class ExtensionMethods { public static void RaiseEvent<T>(this EventHandler<T> eventHandler, object sender, T e) where T : EventArgs { var ev = eventHandler; if (ev != null) ev(sender, e); } } |
|
|
Th69
      

Beiträge: 4798
Erhaltene Danke: 1059
Win10
C#, C++ (VS 2017/19/22)
|
Verfasst: Di 06.05.14 19:26
Oha, da habe ich ja was angestoßen...
Bzgl. thread-safe sollte ich wohl etwas zurückhaltender sein - hier ist nämlich nur die Vermeidung einer möglichen NullReferenceException gemeint.
Ich habe mich hauptsächlich auf die Aussagen von Jon Skeet (Autor von "C# in Depth") berufen, s. z.B. Raising C# events with an extension method - is it bad?
Aber es gibt eine Reihe von anderen Ansichten über Thread-Safety bzgl. der verschiedenen Versionen, s. z.B. Threadsafe Events (Tenor: alle sind nicht thread-safe!).
Weitere Diskussionen gibt es z.B. unter
C# Events and Thread Safety
Raise event thread safely - best practice
...
Fazit: Jetzt weiß ich auch nicht mehr, was ich glauben und verwenden soll?!
Am besten also gar kein Multithreading bei Events verwenden!
Zuletzt bearbeitet von Th69 am Mi 07.05.14 10:08, insgesamt 1-mal bearbeitet
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Di 06.05.14 20:35
Hmm. Nicht böse sein aber ich bin jetzt nicht weiter.
Ich glaube das lese ich noch einige Male 
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Di 06.05.14 20:58
Besser du ignorierst es einfach  Das sind die bösen Details bei der Multithread-Programmierung die dich jetzt nicht stören brauchen. Und selbst dann sind die auch eher akademischer Natur.
Th69 hat folgendes geschrieben: | Fazit: Jetzt weiß ich auch nicht mehr, was ich glauben und verwenden soll?! |
a.) den delegaten zum feuern kopieren
b.) In den EventHandler Methoden auf sich selbst prüfen ob man den disposed ist.
Das Problem das eine EventHandler Methode so noch nach ihrem Abhängen vom Event aufgerufen wird halt ich für äußerst klein. Wenn dann tritt es meiner Meinung fast nur im Context des Disposens auf das mit b. aber abgefangen ist.
Ein Programmiermuster in dem sich Objekte zur Laufzeit an Event hängen und wieder abhängen unabhängig von ihrer eigene Lebensdauer ist mir noch nicht unter gekommen. Und wenn doch .. ääääh .. öhm ... lass ich mir dann was einfallen 
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Mi 07.05.14 05:54
Guten Morgen,
ok dann ignoriere ich eure Unterhaltung. Die hat mich eh nur verwirrt.
Ich versuche mich mal daran, dass irgendwie mit dem Werfen und Fangen umzusetzen.
Bin gespannt.
Gruß
EDIT:
Ralf Jansen hat folgendes geschrieben : | a.) den delegaten zum feuern kopieren
b.) In den EventHandler Methoden auf sich selbst prüfen ob man den disposed ist.
Das Problem das eine EventHandler Methode so noch nach ihrem Abhängen vom Event aufgerufen wird halt ich für äußerst klein. Wenn dann tritt es meiner Meinung fast nur im Context des Disposens auf das mit b. aber abgefangen ist.
Ein Programmiermuster in dem sich Objekte zur Laufzeit an Event hängen und wieder abhängen unabhängig von ihrer eigene Lebensdauer ist mir noch nicht unter gekommen. Und wenn doch .. ääääh .. öhm ... lass ich mir dann was einfallen
|
Sorry, aber ich komme nicht klar. Irgendwie geht hier gar nichts und ich weiß auch nicht so richtig wie ich anfangen soll. Wärt ihr so gut mir einen Denkanstubs zu geben?
Danke
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Mi 07.05.14 09:29
Das was du zitierst gehörte zum Teil den du besser ignorieren solltest
Vielleich hat Th69 die Macht den wenig hilfreichen Teil aus diesem Thread abzutrennen damit die Sicht für dich wieder klarer wird.
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Do 08.05.14 08:16
Hi,
ja das wäre nett, da ich jetzt gar kein Überblick mehr habe bzw nicht weiß wie es geht
Gruß
|
|
Th69
      

Beiträge: 4798
Erhaltene Danke: 1059
Win10
C#, C++ (VS 2017/19/22)
|
Verfasst: Do 08.05.14 09:12
Hallo Talemantros,
ich hatte gestern schon die entsprechenden Beiträge von Ralf und mir in grau eingefärbt.
Hast du denn jetzt noch weitere Fragen zum Thema Ereignisse (events)?
Bezogen auf deine Hauptfrage kommt es darauf an, von wo du die Pinabfrage aufrufst. Wenn du diese innerhalb der MainForm aufrufst, dann kannst du den Pinabfrage-Dialog ja direkt aufrufen. Wenn du jedoch innerhalb deiner Business-Logik diesen aufrufen möchtest, dann solltest du (entsprechend meines Artikels) auf jeden Fall ein Ereignis dafür benutzen, so daß dann von außen festgelegt werden kann, wie der Pinabfrage-Aufruf erfolgen soll. Und bei dem Ereignis würdest du dann eine eigene EventArgs-Klasse benutzen, welche die nötigen Eigenschaften enthält (statt TextEventArgs z.B. PinEventArgs).
Wenn du die Abfrage auch abbrechbar machen möchtest, dann könntest du von CancelEventArgs erben und nach dem Auslösen des Ereignisses die Eigenschaft Cancel abfragen.
PS: Talemantros hat folgendes geschrieben: | Ich versuche mich mal daran, dass irgendwie mit dem Werfen und Fangen umzusetzen. |
Diese Ausdrucksweise benutzt man eher für Exceptions (throw and catch). Bei Ereignissen spricht man eher von Auslösen (oder Feuern) und Behandeln (raise (or fire) and handle).
Und nur der Vollständigkeit wegen: das Hinzufügen einer Methode zu einem Ereignis (mittels +=) nennt man dann Abonnieren (subscribe).
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Do 08.05.14 09:41
Hi,
das mit dem einfärben hatte ich nicht gesehen und danke für die Begriffsbestimmung.
Die Abfrage der Pin soll unterschiedlich sein:
Es gibt Formulare die von der Mainform aufgerufen werden und nur angezeigt werden dürfen, wenn die PinAbfrage gültig ist.
Andere Formulare werden angezeigt und die Abfrage soll beim Drücken des Speichernbuttons drücken und speichern nur ausgeführt werden, wenn die Abfrage gültig ist.
Ich versuche mich im Laufe des Tages mal an deiner Beschreibung, befürchte ich aber dass ich dafür noch nicht weit genug bin. Hatte gehofft es funktioniert mit der Kommunikation von 2 Forms
Gruß
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Fr 09.05.14 10:27
Hi,
also ich bastel seit 1 Tag daran rum und habe rein gar nichts irgendwie, geschweige den würde ich den Quellcode verstehen und bin gerade sehr gefrustet.
Wäre jemand bereit mir ein Beispiel zu posten und mit Erklärungen wie der Quelltext arbeitet und so weiter?
Jetzt habe ich das mit den Modellklassen langsam verstanden und jetzt hänge ich wieder. Schon sehr frustrierend.
Würde mich freuen, wenn sich jemand meiner erbarmt
VG
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Fr 09.05.14 10:41
Versuchen wir mal dein Problem genauer zu Analysieren und zu überlegen wie man das am besten angeht und dann schauen wir uns an welche technischen Hürden dabei zu nehmen sind (Vielleicht stellt sich das mit den Events ja gar nicht)
Annahmen/Fragen
a.) Es gibt per PIN zu schützende Formulare und welche die nicht zu schützen sind?
b.) Die PIN ist Userspezifisch (jeder hat eine eigene) oder Formularspezifisch( jedes Formular hat eine eigene) oder sogar die Kombination aus beidem (jeder Formular+User Kombination seine eigene PIN)
c.) Wenn die PIN Userspezifisch ist soll die dann bei jedem Formularaufruf abgefragt werden oder reicht es das einmal zu tun? Und für die Lebensdauer der Anwendung gilt das dann als authentifiziert?
d.) Wenn du ein Datenmodel hast ist eher das Model per PIN abfrage schützenswert oder tatsächlich die Formulare? Wenn dir nicht ganz klar ist wie das zu beantworten ist. Dann frage ich mal so. Sind bestimmte Objekte per PIN zu schützen (in einer anderen Frage hattest du ja sowas wie Module , Gruppen, Benutzer gehabt) oder eher Vorgänge (aka Benutzer anlegen wäre per PIN zu schützen, Benutzer bearbeiten aber zum Beispiel nicht).
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Fr 09.05.14 11:28
Hallo Ralf,
vielen Dank schon mal
a.) Ja, es gibt Formulare die jeder einsehen kann und die nicht geschützt sind und andere Formulare benötigen der PInAbfrage.
b.) Der Pin ist UserSpezifisch. Jeder Benutzer hat einen eigenen eindeutigen Pin. Über diesen Frage ich dann in der Datenbank ab, ob der Benutzer diese Aktion ausführen darf und wenn ja will ich den Namen des Benutzers in dem neu geöffneten Formular vorhalten um seine Aktion in der Historie zu speichern.
c.) Es sollen immer andere Mitarbeiter an dem System arbeiten und daher soll die Abfrage immer erscheinen und nicht im Hintergrund vorgehalten werden. Der PC steht dann theoretisch in einem öffentlichen Bereich wo jeder halt mal was macht. (so stellt sich das meine Chefin vor)
d.) Ich hoffe dass ich dies jetzt richtig verstehe. Also ich habe die Formulare die ich bisher habe so aufgebaut, dass ein Formular quasi ein Recht ist. Mitarbeiter anlegen bearbeiten und löschen. Von daher würde ich erst mal denken, dass das Formular schützenswert ist. Lasse mich aber auch gern eines besseren belehren.
Wobei ich gerade drüber nachdenke und es vielleicht auch irgendwie doof ist, wenn ein Mitarbeiter ein Formular mit seiner Pin öffnet und dann weg muss und lässt das Fenster auf und dann ein anderer mit seinen Rechten weiter arbeitet. Wäre dann ja irgendwie sinniger, wenn die Abfrage beim Drücken des Buttons kommt (Speichern, Bearbeiten, Löschen)
Gruß
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Fr 09.05.14 11:49
Zitat: | Wäre dann ja irgendwie sinniger, wenn die Abfrage beim Drücken des Buttons kommt (Speichern, Bearbeiten, Löschen) |
Das impliziert das wenn jeder erstmal alles öffnen darf er auch zumindest erstmal alle Daten sehen kann.Ein solches Vorgehen macht gefühlt nur Sinn wenn du nur steuerbare Bearbeitungsrechte hast aber keine Berechtigungsstufen die die Sichtbarkeit von Daten betrifft. Sehen darf dann erstmal jeder alles nur bearbeiten/löschen etc. dürfen nur bestimmte Leute. Jedesmal eine PIN eingeben zu müssen erscheint extrem nerv tötent. Was spricht dagen einfach die Anwendung mit Anmeldedaten/Pin zu schützen? Wenn der Mitarbeiter wechselt hat sich der folgende Mitarbeiter halt selbst an die Anwendung anzumelden und der vorherige muß sich eben abmelden? Das was du mit der PIN vorhast kann ich mir nur in einer Arbeitumgebung vorstellen wo n Leute mehr oder weniger geichzeitig an dem PC arbeiten (stelle mir das so wie sich in einem Laden Bäcker o.ä. eine Kasse teilen) wo ummelden zu lange dauern würde. Da stelle ich mir aber eine PIN eingabe auch extrem aufhaltend vor.
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: Sa 10.05.14 19:06
Hallo Ralf,
Bitte entschuldige die späte Rückmeldung.
Wäre den das Vorgehen so unterschiedlich wenn man die Pin Abfrage mal beim Drücken des Buttons und mal bem öffnen des Forms anzeigt?
Vielleicht könnten wir beides zusammen erarbeiten?
Das mit dem grundsätzlichen Handhaben der Pin Abfrage ist so gewünscht, dass diese immer abgefragt wird.
Wobei ich mich auch nicht wehren würde zu lernen wie man eine dauerhafte Anmeldung im System vorhält.
Viele Grüße
Daniel
|
|
Ralf Jansen
      
Beiträge: 4708
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: So 11.05.14 13:30
Zitat: | Wäre den das Vorgehen so unterschiedlich wenn man die Pin Abfrage mal beim Drücken des Buttons und mal bem öffnen des Forms anzeigt? |
Wahrscheinlich nicht. Aber ich weiß zuwenig darüber was du da hast und wohin du damit willst
Zitat: | Das mit dem grundsätzlichen Handhaben der Pin Abfrage ist so gewünscht, dass diese immer abgefragt wird. |
Um da wirklich das richtige zu raten fehlt mir ausreichend Hintergrund.
Im allgemeinen Fall hätte man zwischen der UI (deinen Formen) und dem Datenmodell eine Logikschicht der man diese Aufgabe wohl zuschanzen würde.
Ich würde mir das gerade so vorstellen das es eine Klassenschicht gibt mit Funktionen wie Speichere, Lade, Bearbeite Objekt X,Y,Z. Diese Methoden erwarten entweder eine PIN die man mit übergibt und die von dieser Schicht dann geprüft und die gewünschte Aktion dann eben abgelehnt oder durchgeführt wird. In diesem Fall wäre der Code des Formularhandlings für die PIN Eingabe irgendwo in den anderen beteiligten Formularen hinterlegt. Oder die genannten Methoden in der Logikschicht lößen eine Event aus der die PIN erfragt worin dann das Handling für die PIN Eingabe Form liegt. Letzteres wäre etwas weniger Aufwand und würde die PIN Abfrage recht gut zentralisieren. Das Verfahren über Events ist aber nicht wirklich gut mit jeder UI Technik verknüpfbar. In einer Web Umgebung wäre das wohl eher hinderlich. Im Moment, um es nicht zu sehr zu komplizieren, würde ich dir eher raten das über einen Event zu machen. Also einen Event der erwartet das in der aufgerufenen EventHandler Methode die PIN eingetragen wird und dann im Code geprüft wird ob der PIN gültig ist.
Im folgenden eine Beispiel mit einer generischen abstrakten Basisklasse für entsprechende Klassen in der angesprochenen Logikschicht die die Aufgabe der Authorizierung durch einen Eventaufruf übernehmen würde. Die Bezeichnung Controller ist etwas belastet den kannst du auch durch was anderes ersetzen das die mehr sagt. Oder wenn dir das zu komplex (das ist eigentlich alles Infrastruktur das macht man genau 1mal) kannst du dir da auch nur den Eventaufrufteil rausklauben und in deinen bestehende Code zum laden/speichern übernehmen.
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: 84: 85:
| public class Employee { }
public class AuthorizationEventArgs : EventArgs { public string PIN { get; set; } public bool Cancel { get; set; } }
public class ControllerBase { public event EventHandler<AuthorizationEventArgs> AuthorizationNeeded;
protected bool IsUserAuthorized { get { AuthorizationEventArgs eventArgs = new AuthorizationEventArgs() { Cancel = false, PIN = string.Empty }; OnAuthorizationNeeded(eventArgs);
if(eventArgs.Cancel) return false;
return IsValidPIN(eventArgs.PIN); } }
private bool IsValidPIN(string pin) { return true; }
private void OnAuthorizationNeeded(AuthorizationEventArgs eventArgs) { EventHandler<AuthorizationEventArgs> handler = AuthorizationNeeded; if (handler != null) handler(this, eventArgs); } }
public interface IController<T> where T : class { bool Save(T obj); T Load(long id); }
public abstract class Controller<T> : ControllerBase, IController<T> where T : class { public bool Save(T obj) { if (!IsUserAuthorized) throw new NotAuthorizedException(); return SaveObject(obj); }
protected abstract bool SaveObject(T obj);
public T Load(long id) { if (!IsUserAuthorized) throw new NotAuthorizedException(); return LoadObject(id); }
public abstract T LoadObject(long id); }
public class EmployeeController : Controller<Employee> { protected override bool SaveObject(Employee obj) { return true; }
public override Employee LoadObject(long id) { return null; } } |
Verwendung von irgendwo wäre dann
C#-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| var controller = new EmployeeController(); controller.AuthorizationNeeded += AuthorizationNeeded;
private void AuthorizationNeeded(object sender, AuthorizationEventArgs e) { e.PIN = "1234567"; }
controller.Save(deineLiebeEmployeeInstanz); |
|
|
Talemantros 
      
Beiträge: 444
Erhaltene Danke: 2
Win7 Proff 64bit
C# (VS2013)
|
Verfasst: So 11.05.14 20:11
Hallo Ralf,
irgendwie ist es total deprimierend. Du gibst dir viel Mühe für guten Code und ich verstehe von Antwort zu Antwort weniger.
Ich habe deinen Code jetzt etliche Male gelesen und versteh fast nichts wie es zusammen spielt, geschweige den wie ich es bei mir einbinden müsste um eine TextBox zu haben wo der User seinen Code eingibt.
Es tut mir sehr leid, wenn ich mich jetzt zu doof anstelle ich würde es gern nur so verstehen, dass ich vielleicht irgendwann mal in der Lage bin es selber zu bauen und statt verständlicher wird es für mich nur komplexer.
Ich weiß es ist viel verlangt, aber könntest du mir das in ein Projekt mit TextBox basteln und eventuell mehr kommentieren?
Bzw. vielleicht Quellen nennen woraus ich vielleicht verstehe was es mit den Abstrakten Klassen etc und deren Zusammenspiel mit dem Interface usw. auf sich hat.
Der Bereich wo Load und SaveObject ist geht der dann nur für das Anlegen eines MItarbeiters aus den vorherigen Treats?
Ich bin überfordert. Sorry
Ich versuche es mir jetzt mal schritt für Schritt auseinder zu nehmen.
EDIT:
Dadurch, dass ich deinen Code nicht verstehe und auch den Aufruf nicht richtig, bzw. nicht zuordnen kann wo die TextBox für den User wäre etc. habe ich Angst dass wir aneinander vorbei reden und du deine Zeit umsonst aufbringst.
Daher nur noch mal kurz zur Sicherheit:
Die PinEingabe soll ein eigens Fenster werden mit einer TextBox, die entweder beim Start des Forms oder beim drücken des SPeicherbutton in einigem x beliebigen Form angezeigt wird.
Sollte die Pinabfrage erfolgreich sein, wird die Funktion des Forms ausgeführt und wenn nicht unterbrochen.
Gruß
|
|