Quelle est la méthode habituelle pour la conception de modèle OOP (accès aux données)

Question

À l'origine, il y avait l'objet DAL que mon BO appelait pour info, puis transmis à l'interface utilisateur. Puis j'ai commencé à remarquer du code réduit dans l'interface utilisateur et il y avait des classes de contrôleur. Quelle est la recommandation décente.

I actuellement la structure moi

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 mis en œuvre 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 mon application

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 

Au départ, je trouve que la La classe partagée I n'a pas eu à créer une nouvelle instance de la DAL chaque fois que besoin de récupérer des données

Dim _orderDAL as New OrderDal 

_orderDAL.GetOrder(1234) 

..... 

Quelle est votre opinion?

Merci

Answer 1

J'ai déjà utilisé votre solution par le passé, et le seul problème auquel j'ai dû faire face est que les méthodes "partagées" ou "statiques" ne prennent pas en charge l'héritage. Lorsque votre application se développe, il se peut que vous deviez prendre en charge différents types de "OrderControllers".

La façon estabilished de soutenir différentes OrderControllers serait, en théorie, de créer une usine:

OrderControllerFactory.ConfiguredOrderController().GetOrder(42); 

Le problème ici est: quel type est retourné par "ConfiguredOrderController()"? Parce qu'il doit avoir la méthode statique "GetOrder (int id)" - et les méthodes statiques ne sont pas prises en charge par l'héritage ou les interfaces. Le moyen de contourner ce problème n'est pas d'utiliser des 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 serez probablement mieux en utilisant des méthodes non statiques pour le contrôleur.

Answer 2

Eh bien votre application ne doit pas être instancié versions séparées des données couche accès, de sorte que vous avez que sous contrôle. Le code Psuedo que vous avez posté est vraiment difficile à lire.

La question est, quelle est votre couche d'accès aux données, et combien y a-t-il? Cela va dicter une bonne partie de ce que vous faites. Si vous persistez dans un fichier alors je pense que ce que vous avez écrit est correct, et si vous avez besoin de le partager avec d'autres contrôleurs dans votre système, il est possible d'envelopper l'élément dans un singelton (frisson).

Si vous effectuez vraiment le traitement des commandes et que vous revenez à une base de données, je pense personnellement qu'il est temps de regarder un ORM. Ces packages gèrent les aspects CRUM pour vous et réduisent le nombre d'éléments que vous devez gérer.

Mon .02 $, et je me réserve le droit de réviser ma réponse une fois que je vois un meilleur exemple.

Answer 3

Je pense qu'il existe plusieurs alternatives énumérées dans cet excellent livre: Patterns of Enterprise Application Architecture. Certains modèles qui peuvent être vous intéresser:

• Active Record
• Table Data Gateway
• Row Data Gateway
• Data Mapper

Answer 4

Je ne peux pas parler des détails VB parce que je ne suis pas un Développeur VB, mais:

Ce que vous faites est un bien-es a établi une bonne pratique en séparant la couche GUI/présentation de la couche de données. L'inclusion d'un code d'application réel dans les méthodes d'événements GUI est une mauvaise pratique (malheureusement également bien établie).

Votre classe de contrôleur ressemble au bridge pattern, ce qui est également une bonne idée si les deux couches doivent pouvoir changer de forme sans que l'autre ne le sache.

Allez-y!

Answer 5

C'est une bonne pratique - surtout quand vous arrivez à un point où le contrôleur devra faire plus que la simple délégation à la couche DAL sous-jacente.