Service Layer vs. Helper Objects?

Question

Ich mag Ihre Meinung zu einem bestimmten Fall haben, bitte. Hier geht es um Service Layer vs. Helper Objects - und ich bin nicht aus ideellen Mustern suchen, sondern nur ein gutes Verständnis von dem, was mein lieber Programmierung Kollegen darüber nachdenken:

In meiner aktuellen Anwendung habe ich ein vollständiges Domain-Modell (LINQ to SQL, extrem leichte Repositories und verwende dann Erweiterungsmethoden über IQueryable <> filtern / sortieren / Reihenfolge basierend auf Geschäftsanforderungen) und dann eine Dienstschicht, die enthält Dienste basierend auf Gruppierung von Verantwortlichkeiten, wie IRegistrationService (Benutzer registrieren, überprüfen Sie die Verfügbarkeit von Login-Namen etc.)

Nun ist die Einschränkung. Ich habe auch einige „Helfer“ Klassen haben, die Dinge wie Verschlüsselung zu tun, und ich habe auch andere sonst ungroupable Elemente in diesem Verzeichnis gefüllt (wie benutzerdefinierte Aufzählungen etc.)

Ich brauche jetzt eine neue Klasse zu erstellen, welche die Erzeugung von benutzerdefinierten Links für meine Anwendung behandelt, die kaum mit verschiedenen Objekten mehr als String.Format ist und nehmen ihre Eigenschaften zu berücksichtigen. Das Innenleben irrelevant sind. Aber ich habe eine harte Zeit eine Art „LinkService“ jetzt Instanziieren das wird das tun - ich fühle mich wie ich mit 100 Diensten, um am Ende werde (und deren Schnittstellen + Implementierung), wenn ich fertig bin

Zur gleichen Zeit, die ich fühle mich nicht wie ich in meinem „Helfer“ Namespace / Verzeichnis einige lose Mischung aus Klassen und andere Sachen erstellen möchten (z Linkmanager).

Was ist zu tun? Wo könnt ihr Sachen setzen, die noch etwas Business-Schicht-Ebene ist, aber zur gleichen Zeit wie beschränken Sie die Anzahl der Elemente in Ihrem Unternehmen / Service-Layer? Wo sehen Sie all die kleinen Hilfsklassen, wie Zwischen Objekte halten, die Vereinfachung und Session Zugriff verwalten (ich nehme an, Sie diese stark typisierte haben wollen - zumindest ich)

?

Lassen Sie mich wissen, was Sie denken? Dank!

Answer 1

Für mich das richtige Werkzeug für den Job ist der Schlüssel. Wenn Sie irgendeine Art von Einrichtung benötigen Links zu generieren, die im Grunde eine Abbildung von Elementeigenschaften zu formatierten Strings ist, dann schreiben Sie eine Anlage, das zu tun. Es muss nicht ein Dienst ... im Gegenteil sein, einen vollständigen geblasenen Service für etwas mit so wahrscheinlich übertrieben ist. Allerdings würde ich nicht nur diese Klumpen in der allgemeinen „Helfer“. Es klingt wie das ist etwas, das einen bestimmten Zweck und die Absicht hat, mit einer bestimmten Art von Verhalten dahinter. Als solche stellen sie in geeigneter Weise in einem Ort für dieses Verhalten geeignet ist ... auch wenn das ist ein neues Projekt.

Ich versuche, nicht einen großen Klumpen von „allgemeinem“ Code in meinen Anwendungen zu haben. Alles hat einen Zweck und implementiert ein bestimmtes Verhalten. Manchmal ist, dass Zweck und Verhalten sehr wiederverwendbar, aber ich versuche immer noch logisch, diese wieder verwendbaren Elemente meiner Domain zu organisieren. Von einem hohen Niveau, sehe ich die meisten meiner Anwendungen aufgeteilt in die folgenden:

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

Eine Menge dieser Art von wieder verwendbarer Funktionalität fällt in einer Art von untern Bereich zwischen Rahmen und Domain. Ein Teil davon kann als einige Basisklassen existieren und / oder Schnittstellen und unterstützen Typen in Framework, mit der anderen Hälfte, die konkreten Implementierungen, wohnhaft in meiner Domain. Es scheint manchmal seltsam, aber die Organisation es auf diese Weise hilft ich meine Domain halte so sauber wie möglich (zu geschäftlichen Belangen gewidmet), während es mich noch zu abstrakt gemeinsamen und wiederverwendbaren Konzepten in der unteren Ebene „Rahmen“ -Typen.