Service Layer vs Helper Object?

Question

Mi piacerebbe avere il vostro parere su un caso specifico, per favore. Si tratta di livello di servizio vs Helper Objects - e non sto cercando di modelli ideali, ma semplicemente una buona comprensione di ciò che i miei cari colleghi di programmazione pensare a questo:

Nella mia applicazione corrente ho un modello di dominio completo (LINQ to SQL, repository estremamente leggero e quindi utilizzare metodi di estensione in tutta IQueryable <> per filtrare / tipo / ordine in base alle esigenze di business), e poi un livello di servizio che contiene i servizi sulla base di raggruppamento delle responsabilità, come IRegistrationService (registrare gli utenti, controllare la disponibilità di nomi di login, ecc.)

Ora l'avvertimento. Ho anche alcune classi "aiuto" che fanno cose come la crittografia, e ho anche farcito altri elementi altrimenti ungroupable in quella directory (come enumerazioni personalizzati, ecc.)

Ho bisogno di creare una nuova classe ora che gestirà la generazione di collegamenti personalizzati per la mia domanda, che è poco più di String.Format con diversi oggetti e di prendere le loro proprietà in considerazione. Il funzionamento interno sono irrilevanti. Tuttavia, ho un momento difficile istanziare una sorta di "linkservice" ora che farò - mi sento come se stessi andando a finire con 100 servizi (e le loro interfacce + attuazione) quando ho finito

Al tempo stesso non mi sento come voglio creare alcuni sciolti mix di classi e altre cose nella mia "Helpers" namespace / directory (ad esempio LinkManager).

Che fare? Dove voi ragazzi mettere la roba che è ancora un po 'di livello livello di business, ma allo stesso tempo come si fa a limitare il numero di elementi nel vostro / livello di servizio di business? Dove ti infili tutte quelle classi helper piccoli, come ad esempio oggetti intermedi in grado di semplificare e gestire l'accesso Sessione (suppongo che si desidera avere questo fortemente tipizzato - almeno io lo faccio)

?

Fatemi sapere cosa ne pensate? Grazie!

Answer 1

Per me, utilizzando lo strumento giusto per il lavoro è la chiave. Se avete bisogno di un qualche tipo di struttura per generare link, che è fondamentalmente una mappatura delle proprietà di entità di stringhe formattate, quindi scrivere una funzione per farlo. Non deve essere un servizio ... al contrario, avere un servizio in piena regola per una cosa del genere è probabilmente eccessivo. Tuttavia, non vorrei solo grumo questo nella vostra "aiutanti" generali. Sembra che questo è qualcosa che ha uno scopo e intento specifico, con uno specifico tipo di comportamento dietro di esso. Come tale, metterlo in una posizione opportunamente adatto per quel comportamento ... anche se questo è un nuovo progetto.

cerco di non avere un enorme pezzo di codice "generale" nelle mie applicazioni. Tutto ha uno scopo e implementa un comportamento specifico. A volte tale scopo e il comportamento sono altamente riutilizzabile, ma ho ancora cercano di organizzare quegli elementi riutilizzabili del mio dominio logicamente. Da un livello alto, vedo la maggior parte delle mie applicazioni diviso in quanto segue:

1. Client
2. API / Servizio
3. Dominio
4. Data Access (opzionale)
5. quadro

Un sacco di questo tipo di funzionalità riutilizzabili cade in una sorta di zona inferiore tra il quadro e di dominio. Parte di esso può esistere come alcune classi base e / o interfacce e tipi di supporto in quadro, con l'altra metà, le implementazioni concrete, residente nel mio dominio. A volte sembra strano, ma l'organizzazione in questo modo mi aiuta a mantenere il mio dominio il più pulito possibile (dedicato alle esigenze delle imprese), mentre ancora mi permette di concetti comuni e riutilizzabili astratte in livello tipi "quadro" più bassi.