Service Layer vs. Helferobjekte?

Question

Ich hätte gerne Ihre Meinung zu einem bestimmten Fall, bitte. Hier geht es um Service Layer vs. Helper Objects - und ich bin nicht auf der Suche nach idealistischen Mustern, sondern lediglich nach einem guten Verständnis dessen, was meine lieben Programmkollegen darüber denken:

In meiner aktuellen Anwendung habe ich ein vollständiges Domain Model (Linq to Sql, extrem leichte Repositories und verwenden dann Erweiterungsmethoden über IQueryable <> zu filtern/sortieren/bestellen auf der Grundlage der Geschäftsanforderungen), und dann eine Service-Schicht, die Dienste basierend auf Gruppierung von Verantwortlichkeiten enthält, wie IRegistrationService (Benutzer registrieren, überprüfen Verfügbarkeit von Login-Namen etc.)

Jetzt der Vorbehalt. Ich habe auch einige "Helper" -Klassen, die Dinge wie Verschlüsselung tun, und ich habe auch andere nicht gruppierbare Elemente in diesem Verzeichnis gestopft (wie benutzerdefinierte Enums usw.)

Ich muss jetzt eine neue Klasse erstellen, die behandelt wird die Generierung von benutzerdefinierten Links für meine Anwendung, die kaum mehr als String.Format mit verschiedenen Objekten und unter Berücksichtigung ihrer Eigenschaften ist. Die inneren Abläufe sind irrelevant. Es fällt mir jedoch schwer, jetzt eine Art "LinkService" zu erstellen, der das tun wird - ich glaube, ich werde am Ende 100 Dienste (und ihre Schnittstellen + Implementierung) haben, wenn ich fertig bin.

Zur gleichen Zeit habe ich nicht das Gefühl, ich möchte eine lose Mischung von Klassen und andere Sachen in meinem Namespace/Verzeichnis "Helpers" (z. B. LinkManager) erstellen.

Was ist zu tun? Wo setzen Sie Dinge ein, die immer noch Business-Level-Niveau haben, aber gleichzeitig, wie begrenzen Sie die Anzahl der Elemente in Ihrem Business/Service-Layer? Wo steckst du all diese kleinen Hilfsklassen, wie zB Zwischenobjekte, die den Session-Zugriff vereinfachen und verwalten (ich nehme an, du willst dies stark typisiert haben - zumindest ich)?

Lassen Sie mich wissen, was Sie denken? Vielen Dank !

Answer 1

Für mich ist die Verwendung des richtigen Tools für den Job der Schlüssel. Wenn Sie eine Art von Einrichtung zum Generieren von Verknüpfungen benötigen, bei der es sich im Grunde um eine Zuordnung von Entitätseigenschaften zu formatierten Zeichenfolgen handelt, schreiben Sie eine entsprechende Funktion. Es muss kein Service sein ... im Gegenteil, einen vollwertigen Service für so etwas zu haben ist wahrscheinlich zu viel. Allerdings würde ich das nicht einfach in Ihre allgemeinen "Helfer" einteilen. Es klingt so, als ob dies etwas ist, das einen bestimmten Zweck und eine bestimmte Absicht hat, mit einer spezifischen Art von Verhalten dahinter. Stellen Sie es daher an einem Ort auf, der für dieses Verhalten geeignet ist ... auch wenn das ein neues Projekt ist.

Ich versuche in meinen Anwendungen keinen riesigen "allgemeinen" Code zu haben. Alles hat einen Zweck und implementiert ein spezifisches Verhalten. Manchmal sind dieser Zweck und dieses Verhalten in hohem Maße wiederverwendbar, aber ich versuche immer noch, diese wiederverwendbaren Elemente meiner Domäne logisch zu organisieren. Von einem hohen Niveau, sehe ich die meisten meiner Anwendungen in folgende unterteilt:

1. Kunde
2. API/Dienstleistung
3. Domain
4. Data Access (Optional)
5. Rahmen

Viele dieser wiederverwendbaren Funktionen fallen in eine niedrigere Region zwischen Framework und Domain. Ein Teil davon kann als Basisklassen und/oder Schnittstellen und unterstützende Typen in Framework existieren, während die andere Hälfte, die konkreten Implementierungen, innerhalb meiner Domain liegen.Es scheint manchmal seltsam, aber wenn ich es so organisiere, hilft es mir, meine Domäne so sauber wie möglich zu halten (für Geschäftsangelegenheiten), während ich immer noch allgemeine und wiederverwendbare Konzepte in tiefere "Framework" -Typen abstrahiere.