steinadler

Ah okay, das heißt, das Paradebeispiel von Ninject public class WarriorModule : NinjectModule { public override void Load() { Bind<IWeapon>().To<Sword>(); Bind<Samurai>().ToSelf().InSingletonScope(); } } ergibt auch nur Sinn, solange man beim Programmstart festlegt, ob man "Sword" auswählt. Wenn man nun das Werkzeug während der Programmlaufzeit wechseln möchte, also als "Sword" etwas anderes machen? Das würde doch dann auch nicht mehr mit DI funktionieren oder? Ich habe bisher immer konventionell ohne DI programmiert, mit Ereignissen usw.

Es ist eher so, dass der Kunde einen Sensor kauft und die PC-Software permanent aktuell hält. Daraus ergibt sich: (alter) Sensor neue Software. Inzwischen gibt es jedoch eine neue Sensor-Firmware, welche von der bereits aktuellen PC-Software schon unterstützt wird. Man musste bisher immer Firmware aktualisieren und dann die Software neu starten. Diesen Neustart möchte ich gern verhindern. Oder: Kunde trennt die Verbindung zum Sensor und tauscht den Sensor zu einem neueren Modell, welches auch von der Software unterstützt wird. Ich müsste also meine Geräteinstanzen während der Programmlaufzeit irgendwie austauschen können. Wie gesagt, vielleicht ist DI dafür aber auch nicht gemacht.

Es handelt sich dabei um eine Assembly, welche sämtliche Firmwareversionen des Sensors abdeckt. Man hat ein SensorBuilder-Klasse mit der man Connect() aufruft und irgendwann per Event ein Interface auf den Sensor zurückbekommt. Die Assembly ändert sich praktisch nicht, nur die Firmwareversion des Controllers.

Die Begriffe Controller und Steuerung sind etwas unglücklich gewählt, das stimmt. Controller ist ein Mikrocontroller und Steuerung ist eigentlich eine StateMachine/Schrittkette. Prinzipiell habe ich eine StateMachine, welche einen Ablauf beinhaltet (etwas wird vom Sensor eingelesen und der Controller verarbeitet es; anschließend gibt ein Drucker ein Etikett aus, z.B.). Diese Schrittkette gibt es im Programm nur einmal. Bisher habe ich dieser Schrittkette per Konstruktor jeweils die Instanzen von Sensor, Controller und Drucker übergeben. Problem: Macht man ein Firmware-Update des Sensors und verbindet den Sensor neu, dann wird eine neue Instanz des Sensors erzeugt, da für die neue Firmware eine spezielle Implementation benötigt wird. Durch die Constructor-Injection musste bisher immer nach Firmware-Update das Programm neu gestartet werden - das wollte ich gern vermeiden. Wie sage ich jetzt der Schrittkette, dass sich die Sensorinstanz geändert hat? Ich wollte die Schrittkette eigentlich nicht neu erstellen sondern nur die Sensorinstanz austauschen. Wenn DependencyInjection dafür völlig ungeeignet ist, dann mach ich es auf konventionellem Weg mit Events und einer Setter-Methode, die die Geräteinstanz austauscht.

Genau, diese dre Klassen. Ich habe noch jeweils eine Klasse SensorBuilder. Diese besitzen eine Connect-Methode und ein Event, welches ausgelöst wird, sobald eine entsprechende Instanz erzeugt wurde. Dieses Erzeugen passiert, nachdem während Connect() die Seriennummer und Version des Gerätes geprüft wurden. Das ganze läuft asynchron, bis eben das Event ausgelöst wird. Die Frage ist nun, wie ich die Instanz an meine Controller-Klasse weitergebe. Ich möchte ja gern DI nutzen. Aber ich habe bisher keine Möglichkeit gefunden, dass ich die Instanz des Sensors (z.B. beim neu verbinden) in meiner Controller-Klasse verändern kann.

Hallo, bei einem Projekt benötige ich zwei Geräte, einen Sensor und eine Steuerung. Ebenso habe ich eine Klasse 'Control' die beide Geräte miteinander kommunizieren lässt. Diese bekommt dann von Sensor und Steuerung jeweils eine Instanz. Allerdings bekomme ich erst nach dem Verbinden zum Sensor eine entsprechende Instanz zurück (je nach Firmware-Version). Wenn ich mich nun während der Programmlaufzeit vom Sensor trenne und neu verbinde, könnte es sein, dass sich die Instanz des Sensors ändert. Wie übergebe ich denn meiner 'Control'-Klasse am besten die beiden Instanzen? Lässt sich das per DependencyInjection überhaupt umsetzen (aktuell nutze ich Ninject)? Oder erzeuge ich besser eine übergeordnete Klasse 'Device' welche meine beiden Geräteinstanzen enthält und übergebe diese der 'Control'-Klasse? Danke schonmal

Das kommt drauf an, ob man jede angefangene Stunde rechnet. Rein fürs Schauen würden theoretisch paar Sekunden ausreichen. Das läuft darauf hinaus, dass eine Vergütung gegen Null geht, aber man trotzdem (gerade am Wochenende) eingeschränkt ist.

Was es dem Kunden nützt, steht auf einem anderen Blatt - das ist jetzt so gegeben. Evtl. geht der Kunde davon aus, das meist schon eher jemand am Apparat ist, das ist aber sein Problem. Wie Maniska sagte, alle 6 Stunden aufs Telefon schauen. Nach obiger Rechnung gibt das je Woche 21,3 Stunden (128 geteilt durch 6). Setzt man jetzt hierfür den normalen Stundenlohn an? Habe irgendwo auch mal was von 12,5% vom normalen Stundenlohn gelesen.

Deswegen habe ich extra nen Thread gestartet, da ich über solche Zeiten nicht viel weiter gefunden habe.

Rein theoretisch müsste man ja aller 6 Stunden aufs Telefon schauen. Fraglich wäre, welche Zeit man dann als "Rufbereitschaftszeit" ansetzen kann. Eben diese 2,6 je Wochentag?

Die 2,6 Stunden? Die verbleibende Resttageszeit (24-8 = 16) geteilt durch die Reaktionszeit, in der man zurückgerufen haben muss. Fällt die Anlage um 22 Uhr aus hätte man ggf. innerhalb der 6 Stunden die Anlage wieder am Laufen, falls man telefonisch weiterhelfen kann.

In dem Fall ist gemeint: innerhalb 6 Stunden muss man per Telefon reagiert haben (Telefonbereitschaft).

Für die reine Bereithaltung? Und die Stundenanzahl laut meiner Rechnung oben?

Wie fließen da die Reaktionszeiten ein? So hier: Wochentag: 16 Stunden / 6 Reaktionszeit = 2,6 Stunden Sa/So: 24 / 6 = 4 Stunden Macht für die Woche: 5 Tage * 2,6 Stunden + 2 Tage * 4 Stunden = 21 Stunden Korrekt? Es geht hier rein um die Vergütung der Bereithaltung zur Rufbereitschaft; die einzelnen Anrufe/Einsätze werden gesondert vergütet.

Hallo ihr Lieben, folgende Randbedingung: Rufbereitschaft mit einer (Telefon-)Reaktionszeit von 6 Stunden, vor Ort 24 Stunden (in dieser Zeit muss man beim Kunde sein). Mo-Fr. von 16-07 Uhr. Sa./So. ganztags Was für eine Vergütung würdet ihr da ansetzen? Im Netz habe ich nichts über diese Reaktionszeiten gefunden. Danke für eure Meinungen