Come evitare le regole aziendali nel repository?

La logica aziendale non è la query che restituisce all'Impiegato lo stipendio più alto: i database sono eccezionali e devi consentire al database di farlo per te tramite il repository. La logica aziendale è ciò che fai dopo aver recuperato il dipendente più altamente compensato.

Hai bisogno di due livelli per eseguire questo. Uno sarà il livello DAO e uno sarà il livello di servizio. Tutta la tua logica di business deve essere definita (o iniettata da una fonte esterna) nel livello di servizio. Tutti i metodi necessari per recuperare i dati dal database o da un'altra fonte dovrebbero essere definiti nel livello DAO. Il livello di servizio chiamerà il livello DAO e applicherà alcune regole su di esso e restituirà il risultato. Ciò ti aiuterà a completare il disaccoppiamento delle tue regole e persistenza.

Ma nel tuo caso, l'esecuzione di una query SQL diretta con dipendenti con salario maggiore avrà prestazioni elevate rispetto al seguente pattern Service-DAO. In questo caso, puoi modificare la logica di business nel livello di servizio per selezionare la stringa di query appropriata in Servizio livello e passa la query (o la condizione della query) a DAO e ottieni il risultato.

Poiché uno stipendio, la sua presentazione e il calcolo del database sono abbastanza naturali e non hanno un dominio rigido, non lo chiamerei qui la logica aziendale. È solo una query ORDER BY per il database.

Lascia che ti dia un altro esempio con la logica aziendale:

Se desideri avere il dipendente più "redditizio" e ci sono alcuni valori specifici del dominio come "probabilità di completamento in tempo nei progetti" e "fattore assenza di malattia", e almeno il salario, allora potrebbero esserci alcuni pesi per il calcolo del fattore di punteggio che sarebbe la logica aziendale.

Conclusione:

Tieni presente che esistono quadri con repository privi di DI, quindi sono possibili solo le operazioni dbal. In altre parole, un componente della logica aziendale dovrebbe essere in grado di utilizzare DI.

Secondo me i repository dovrebbero essere semplici e dipendono solo dal dbal. Ordinare e semplice dove sono a posto. Partecipare e il calcolo su diverse entità non è il lavoro del repository.

Quindi lascerei le query semplici a un repository che non ha alcuna logica aziendale e crea servizi per query più complesse, che hanno una logica aziendale.

Tutto sommato credo sia più basato sull'opinione pubblica.

La definizione di un Dipendente (in base al modello di archiviazione esistente) è una regola aziendale (è una definizione, quindi è un fatto).

Primo articolo del manifesto delle regole aziendali ( link ).

È assolutamente OK implementare questo livello basso nel tuo repository e basta proxyarlo dal tuo livello di servizio. Qualcosa come:

// repo contract
public interface IEmployeeRepository {
    public Employee GetHighestPaidEmployee();
}

// service layer contract
public interface IEmployeeService {
    public Employee GetHighestPaidEmployee();
}

// service impl
public class EmployeeService : IEmployeeService {
    private readonly IEmployeeRepository employeeRepository;

    // constructor here for DI to hook onto

    public Employee GetHighestPaidEmployee() {
        return employeeRepository.GetHighestPaidEmployee();
    }
}

Oppure, se vuoi essere più generico, implementa qualcosa come public IQueryable<Employee> GetEmployees(string sortColumn, SortDirection sortDirection); sul tuo repository e chiamalo dal tuo livello di servizio usando qualcosa come return employeeRepository.GetEmployees("Salary", SortDirection.Descending).FirstOrDefault();

Scusa la mia inclinazione C #, non ho idea di quale lingua stai usando. Questi concetti dovrebbero tradursi in altre lingue, tuttavia, non sono così familiare con la sintassi.