Qual è il modo comune per la progettazione di pattern OOP (accesso ai dati)

StackOverflow https://stackoverflow.com/questions/151769

  •  02-07-2019
  •  | 
  •  

Domanda

Inizialmente c'era l'oggetto DAL che il mio BO chiamava per informazioni e poi passava all'interfaccia utente. Poi ho iniziato a notare il codice ridotto nell'interfaccia utente e c'erano classi del controller. Qual è la raccomandazione decente.

Attualmente strutturo il mio 

Public Class OrderDAL

    Private _id Integer
    Private _order as Order

    Public Function GetOrder(id as Integer) as Order

        ...return Order

    End Function

End Class

quindi ho classi controller (recentemente implementato questo stile) 

Public Class OrderController

    Private Shared _orderDAL as new OrderDAL

    Public Shared Function GetOrder(id) As Order

        Return _orderDAL.GetOrder(id)

    End Function

End Class

Quindi nella mia applicazione 

My app Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        msgbox(OrderController.GetOrder(12345).Customer.Name)

    End Sub


End app

Inizialmente ho scoperto che con la classe condivisa non dovevo continuare a creare una nuova istanza di DAL ogni volta che dovevo recuperare i dati 

Dim _orderDAL as New OrderDal

_orderDAL.GetOrder(1234)

.....

Qual è la tua opinione?

Grazie

È stato utile?

Soluzione

Ho usato la tua soluzione in passato e l'unico problema che ho riscontrato è che " Condiviso " o " statico " i metodi non supportano l'ereditarietà. Quando l'applicazione cresce, potrebbe essere necessario supportare diversi tipi di " OrderController " ;.

Il modo stabilito di supportare diversi OrderController sarebbe, in teoria, quello di creare una fabbrica: 

OrderControllerFactory.ConfiguredOrderController().GetOrder(42);

Il problema qui è: quale tipo viene restituito da " ConfiguredOrderController () " ;? Perché deve avere la statica " GetOrder (int id) " metodo - e i metodi statici non sono supportati da ereditarietà o interfacce. Il modo per aggirare questo non è usare metodi statici nella classe OrderController. 

public interface IOrderController
{
    Order GetOrder(int Id)
}

public class OrderController: IOrderController
{
    public Order GetOrder(int Id)
    {}
}

e 

public class OrderControllerFactory()
{
    public IOrderController ConfiguredOrderController()
    {}
}

Quindi, probabilmente starai meglio usando metodi non statici per il controller.

Altri suggerimenti

Penso che ci siano diverse alternative elencate in questo eccellente libro: Patterns of Enterprise Application Architecture . Alcuni schemi che potrebbero interessarti:

Beh, la tua applicazione non dovrebbe creare un'istanza di versioni separate del livello di accesso ai dati, quindi hai tutto sotto controllo. Tuttavia, il codice Psuedo che hai pubblicato è davvero difficile da leggere.

La domanda è: qual è il tuo livello di accesso ai dati e quanto c'è? Questo detterà un bel po 'di quello che fai. Se stai cercando un file, penso che ciò che hai scritto vada bene, e se hai bisogno di condividerlo con altri controller nel tuo sistema, è possibile avvolgere l'oggetto in un singelton (shudder).

Se stai davvero eseguendo l'elaborazione degli ordini e persistendo in un database, penso personalmente che sia il momento di guardare un ORM. Questi pacchetti gestiranno gli aspetti CRUM per te e ridurranno il numero di articoli che devi mantenere.

I miei $ 0,02 e mi riservo il diritto di rivedere la mia risposta quando vedrò un esempio migliore.

Non posso parlare con i dettagli VB perché non sono uno sviluppatore VB, ma:

Quello che stai facendo è una buona pratica consolidata, che separa il livello GUI / presentazione dal livello dati. Includere il codice dell'applicazione reale nei metodi di evento della GUI è una cattiva pratica (purtroppo anche consolidata).

La tua classe di controller assomiglia al modello di ponte che è anche una buona idea se entrambi i layer devono essere in grado di cambiare forma senza che l'altro ne sia a conoscenza.

Vai avanti!

È una buona pratica, specialmente quando si arriva a un punto in cui il controllore dovrà fare qualcosa di più della semplice delega al DAL sottostante.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top