Cosa dovrebbe essere nella mia classe di logica aziendale

2

Al momento stiamo svolgendo un dibattito interno su come strutturare le nostre classi di business logic. Al momento strutturiamo le nostre classi di business in questo modo:

public class OrderBL
{
    public void CreateOrder(OrderDTO order)
    {
        //save order
        //send email
    }

    public void CancelOrder(OrderDTO order)
    {
        //save order
        //send email
    }

    public void MarkOrderAsDispatched(OrderDTO order)
    {
        //save order
        //send email
    }

    //other private methods too
}

Usando il nostro metodo attuale sopra, troviamo che le classi crescono molto rapidamente e possono diventare confuse sui grandi progetti.

C'è qualche dibattito sul fatto che dovremmo cambiare le nostre classi di business per assomigliare al seguente:

public class CreateOrderBL
{
    public void RunLogic(OrderDTO order)
    {
        CreateOrder();
        SendEmail();
    }

    private voide CreateOrder()
    {

    }

    private void SendEmail()
    {

    }
}

Il vantaggio di avere questo è che le classi sono più facili da capire e sono piccole, tuttavia lo svantaggio è che il numero di classi aumenta.

Qual è il modo corretto per avvicinarsi a questo?

    
posta user1786107 20.03.2016 - 14:39
fonte

3 risposte

4

Il modo "corretto" è quello che soddisfa in modo efficace i requisiti non funzionali della tua applicazione per la manutenzione, le prestazioni, ecc.

Ciò di cui hai bisogno è un livello della logica di business o Livello di servizio . Questi livelli convertono i metodi CRUD in operazioni aziendali reali. Sì, avrai più lezioni, ma quelle lezioni saranno organizzate meglio e avranno una migliore separazione delle preoccupazioni.

Eviterei l'uso all'ingrosso dei metodi di stile Execute() . Raggruppa le tue classi in aggregati aziendali come OrderProcessing o Shipping e dai ai tuoi metodi nomi significativi come ProcessOrder() (che chiama CreateOrder e SendEmail).

    
risposta data 20.03.2016 - 15:33
fonte
0

Stai considerando di passare da un modello orientato a oggetto commerciale a un modello orientato operazione commerciale / transazione . Molti sistemi transazionali sono costruiti su un simile approccio.

Ma come manterrai i vantaggi dell'approccio orientato agli oggetti? La sfida sarà quella di tenere traccia di qualche parte degli interni dell'ordine. E per controllare la visibilità di questi interni per il mondo esterno.

Quindi non solo avrai un numero crescente di classi. Ma avrai anche un aumento significativo dell'interazione tra classi, ad esempio tra CreatOrderBL e alcuni OrderBL che devono mantenere gli interni e infine gestire la persistenza dell'oggetto.

Conclusione: per definizione aumenterai la complessità del tuo modello. Per comprendere una delle classi più semplici, è necessario avere una buona conoscenza di tutte le classi correlate.

    
risposta data 20.03.2016 - 15:28
fonte
0

"Corretto" è soggettivo e ognuno avrà la propria idea di cosa significa "corretto". A mio avviso, corretto significa che il codice funziona ed è facile da mantenere ed estendere. Sono a favore di un modello di progettazione che separa il flusso di lavoro, le azioni e le entità.

In questo esempio, "ordine" è un'entità e le azioni sono le cose che si possono fare con l'ordine (CRUD) e il flusso di lavoro è la logica aziendale che orchestra le azioni per ottenere un risultato aziendale. Idealmente, non vuoi che la tua logica aziendale manipoli direttamente la tua entità, e dipenda solo dal livello "azione" (che sa come manipolare le entità di conseguenza).

Il motivo è perché lungo la strada ci si può ragionevolmente aspettare che l'oggetto "ordine" cambi, ad esempio potrebbe migrare da una piattaforma di database a un'altra. Disattivando la logica aziendale dall'oggetto entità, è possibile modificare l'oggetto ordine senza dover revisionare il livello della logica aziendale.

Con la stessa idea, sarebbe ragionevole progettare in modo tale che il tuo livello di business logic non tocchi mai nulla e passi sempre attraverso un livello "adattatore". Ad esempio, i bit di codice che inviano l'e-mail dovranno essere rivisti se il tuo sistema di posta elettronica è cambiato.

Per questi motivi, preferisco il secondo design rispetto al primo. Nell'attuale (in alto) design, quando cambiano il sistema degli ordini e / o i livelli di e-mail e / o persistenza (database), ci sono molti posti da modificare di conseguenza nella tua logica aziendale. Ciò ostacolerà la flessibilità nell'accogliere le modifiche e aumentare la complessità richiesta per modificare l'app in risposta ai requisiti aziendali.

    
risposta data 20.03.2016 - 15:43
fonte

Leggi altre domande sui tag