Come scrivo il mio BLL per renderlo riutilizzabile?

Naviga le tue risposte
2

La maggior parte è stata scritta 4-5 anni fa. Gli obiettivi a lungo termine del nostro team sono l'utilizzo di Entity Framework. Anche se non lo faremo subito perché le nostre scadenze non ci permettono di farlo. Ora abbiamo la nostra struttura. Voglio essere in grado di separare il livello della logica aziendale in modo tale da non dover essere riscritto quando ci spostiamo su EF. Per favore guidaci con le migliori pratiche, avvisaci in questa direzione.

Il nostro livello logico aziendale è molto frammentato oggi (codice UI dietro + stored procedure / funzioni classi persistenti SqlServer / C #): cosa succede se voglio segregarlo completamente e tracciare una linea molto marcata tra Storage | DAL | Logica aziendale | UI

  1. Voglio sapere se è giusto spostare completamente il BLL in stored procedure SQl o deve essere totalmente in classi C #?

  2. Anche per evitare di riscrivere il BLL, visto che ci sposteremo su EF alla fine. Che cosa dovrei fare per poter utilizzare prontamente l'intero BLL con EF senza modificare il codice.

  3. Molte stored procedure (che hanno il BL) si trovano nel DB di archiviazione stesso. Separare il BLL significa che gli SP e le funzioni dovrebbero essere in un database completamente diverso? o per tutti gli scopi pratici è giusto per loro essere nello stesso DB?

Ho visto più domande su SO che sono state davvero utili, ma non sono riuscito a ottenere un'immagine chiara della soluzione o consiglio di cercare, quindi ho messo tutto in un solo post.

Per favore correggimi se sbaglio. Sono un principiante quando si tratta di design del sistema. Voglio essere in grado di prevedere quello che sto provando prima di implementarlo.

    
posta Pavitar 19.09.2014 - 19:10
fonte

2 risposte

1

  1. Penso che la logica dovrebbe rimanere sempre il più possibile nel codice dell'applicazione. Il codice dell'applicazione è controllato in versione ma il tuo DB no. Se si dispone di un codice che si basa su una logica nel DB, è possibile che si verifichino problemi in seguito. Quindi, se non stai modificando il tuo DB in uno stato maggiore, mantieni la logica nel codice dell'applicazione.

  2. Riorganizza il tuo DAL ma non cambia l'interfaccia / le funzioni o il modo in cui la BLL comunica con il DAL. In questo modo puoi facilmente passare a EF senza refactoring del tuo BLL. E quando refactoring, pensa sempre al SRP e non pensare troppo in grande. Non è necessario riscrivere tutto in una volta, basta prendere una piccola porzione alla volta.

  3. Va bene per loro essere nello stesso DB, ma come ho scritto prima, prova a spostarli nel codice dell'applicazione. La maggior parte della logica dovrebbe essere lì, tranne alcuni importanti cambiamenti di stato del tuo DB, quindi va bene che sia in una stored procedure.

risposta data 20.09.2014 - 20:07
fonte
0
  1. Dipende da te
  2. Utilizza i proiettili di traccia, un POC
  3. n / a

Se l'obiettivo a lungo termine è utilizzare EF, quindi spostati su EF ora. Se le mangiatoie non ottengono i benefici, allora prova a convincere poi davvero tanto! Comprali libri e così via ...

Se non sai come EF si adatta alla tua soluzione? Crea un POC su una piccola parte del sistema (un caso d'uso), ma assicurati che sia implementato attraverso tutti i livelli della tua applicazione. Allora saprai come ti si adatta EF e potresti avere una migliore comprensione dello scopo di usarlo tutto insieme. Dovresti essere in grado di farlo senza incidere sulla scadenza.

Buona fortuna!

    
risposta data 20.09.2014 - 07:30
fonte

Leggi altre domande sui tag

Come evitare la duplicazione del modello nelle applicazioni web JavaEE con un front-end JSON ASP.NET come gestire le impostazioni dell'applicazione esterna