Quelle est la manière habituelle de concevoir un modèle de POO (accès aux données)?

Question

À l'origine, il y avait l'objet DAL que mes BO appelaient pour plus d'informations puis passaient à UI. Ensuite, j'ai commencé à remarquer une réduction de code dans l'interface utilisateur et il y avait des classes de contrôleur. Quelle est la recommandation décente.

Je structure actuellement le mien

Public Class OrderDAL

    Private _id Integer
    Private _order as Order

    Public Function GetOrder(id as Integer) as Order

        ...return Order

    End Function

End Class

alors j'ai des classes de contrôleur (récemment implémenté ce style)

Public Class OrderController

    Private Shared _orderDAL as new OrderDAL

    Public Shared Function GetOrder(id) As Order

        Return _orderDAL.GetOrder(id)

    End Function

End Class

Puis dans ma candidature

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

À l'origine, je trouvais qu'avec la classe partagée je n'avais pas besoin de créer une nouvelle instance du DAL chaque fois que j'avais besoin de récupérer des données

Dim _orderDAL as New OrderDal

_orderDAL.GetOrder(1234)

.....

Que pensez-vous?

Merci

Answer 1

J'ai déjà utilisé votre solution par le passé et le seul problème que j'ai rencontré est celui de "Partagé". ou " statique " les méthodes ne supportent pas l'héritage. Lorsque votre application se développe, vous devrez peut-être prendre en charge différents types de "OrderControllers".

La manière habituelle de soutenir différents contrôleurs de commandes serait, en théorie, de créer une usine:

OrderControllerFactory.ConfiguredOrderController().GetOrder(42);

Le problème est le suivant: quel type est renvoyé par "ConfiguredOrderController ()"? Parce qu’il doit avoir la valeur statique & Get; GetOrder (int id) " method - et les méthodes statiques ne sont pas prises en charge par l'héritage ou les interfaces. La solution consiste à ne pas utiliser de méthodes statiques dans la classe OrderController.

public interface IOrderController
{
    Order GetOrder(int Id)
}

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

et

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

Par conséquent, vous aurez probablement intérêt à utiliser des méthodes non statiques pour le contrôleur.

Answer 2

Je pense que cet excellent livre contient plusieurs alternatives: Modèles d'architecture d'application d'entreprise . Certains modèles qui pourraient vous intéresser:

• Enregistrement actif
• Passerelle de données de table
• passerelle de données en ligne
• mappeur de données

Answer 3

Votre application ne devrait pas instancier des versions distinctes de la couche d’accès aux données. Vous avez donc le contrôle sur celle-ci. Le code Psuedo que vous avez posté est vraiment difficile à lire.

La question est la suivante: quelle est votre couche d’accès aux données et combien en contient-elle? Cela va dicter une bonne partie de ce que vous faites. Si vous conservez un fichier dans un fichier, je pense que ce que vous avez écrit est correct et que vous devez le partager avec d'autres contrôleurs de votre système, il est possible d'envelopper l'élément dans un singelton (frémissement).

Si vous traitez réellement une commande et que vous persistez dans une base de données, je pense personnellement qu'il est temps de regarder un ORM. Ces packages géreront les aspects CRUM pour vous et réduiront le nombre d'éléments que vous devez gérer.

Mon 0,02 $, et je me réserve le droit de réviser ma réponse dès que je verrai un meilleur exemple.

Answer 4

Je ne peux pas parler des détails de VB car je ne suis pas un développeur de VB, mais:

Ce que vous faites est une bonne pratique bien établie, séparant la couche d'interface graphique / de présentation de la couche de données. L'inclusion de code d'application réel dans les méthodes d'événement de l'interface graphique est une mauvaise pratique (malheureusement également bien établie).

Votre classe de contrôleur ressemble au modèle de pont , ce qui est également une bonne idée si les deux couches doivent pouvoir changer de forme sans que les autres le sachent.

Allez-y!

Answer 5

C’est une bonne pratique - surtout lorsque vous arrivez à un point où le contrôleur devra faire plus que simplement déléguer au DAL sous-jacent.