Namenskonvention 3-Layer-Architektur
Hallo zusammen,
gibt es eigentlich Namenskonventionen für die Klassen des BusinessLayer?
Ich habe in unseren Projekten bisher folgende Benennung entdeckt:
CustomerManager.cs
CustomerService.cs
CustomerController.cs
Eigentlich finde ich das erste am besten, denn Service fände ich eher für WCF passend und Controller eher für MVC-Anwendungen.
Wie handhabt ihr das?
Viele Grüße
LuckyStrike
Ich würd so nennen wie es mir am einleuchtendsten scheint 😃
Wenn etwas kontrolliert/überwacht wird, nenn ich es Controller und nicht irgendwie anders, nur weil man die meisten sonstigen ähnlichen Klassen auch anders nennt.
Und dank Refactoring ists auch schnell wieder umbenannt, wenn der Name im Laufe der Programmierung nicht mehr zutrifft.
Customer?
Also "ohne alles" (für die Klasse, die einen Kunden repräsentiert).
Für den Ort, wo die Customer herkommen würde ich eher zu CutsomerRepository oder CustomerDatastore raten.
"Manager" ist IMHO ein bisschen "nichts-sagend" - da kann alles und nichts dahinterstecken.
Es gibt noch ein Business Object mit dem Namen Customer und ein auch noch ein CustomerData/CustomerRepository für den Datenzugriff.
Und was soll dann die Klasse können, für die ein Name gesucht wird?
Das Beispiel wäre eine Klasse aus dem BLL. Die Klasse würde beispielsweise eine Validierung der Benutzereingaben durchführen, ein Customer-Objekt erzuegen und es anschließend an den DAL zu Speicherung übergeben. Also allg. die Anwendungs-/Geschäftslogik abbilden.