micgro42
commented
9 years ago Mh, die Containerklassen sind zur einfacheren Kommunikation zwischen den Layern gedacht. Was ich vermeiden will ist ein Interface voll mit Funktionen wie
void addEmployee (int id, String firstName, String lastName, Date birthdate, String placeOfBirth, String street, String houseNumber, String zipCode, String city, String profession, int paymentLevel, ...);Das kann dann alles in das Objekt gepackt werden und dann übergebe ich nur noch ein einzelnes Objekt. Das Beispiel ist jetzt etwas übertrieben für unseren konkreten Fall, aber hoffentlich anschaulich. Die Idee dahinter: http://www.refactoring.com/catalog/introduceParameterObject.html
Aber so ganz sicher bin ich mir damit auch nicht. Was denkst du?
Controller und Model sind für unser Problem vermutlich auch etwas Overkill. Aber ich hatte Spaß daran mich da einzuarbeiten. Vermutlich würde hier auch das Proxy-Entwurfsmuster ausreichen. Das MVC-Muster würde hier funktionieren wenn wir uns das Model als Beobachter des Storage vorstellen und den View als Beobachter des Models. Aber das werden wir so nicht implementieren. Der Controller wird also eine Mischung aus Controller und Proxy werden.
ghost
Die Klassen in "Container" sehen aus wie Modelle .... als ob die eher was für einen Ordner "Models" wären, was steht da wohl dahinter?
Ich dachte immer man hätte Controller nur im Webbericht, da sie aus dem MVC-Prinzip kommen und man diese zumindest unter .Net im Webberich einsetzen muss. ^^