¿Cuál es la forma común para el diseño de patrones OOP (acceso a datos)

Question

Originalmente estaba el objeto DAL que mi BO solicitó información y luego pasó a la interfaz de usuario. Luego comencé a notar un código reducido en la interfaz de usuario y había clases de controlador. ¿Cuál es la recomendación decente?

Actualmente estructuro el mío

Public Class OrderDAL

    Private _id Integer
    Private _order as Order

    Public Function GetOrder(id as Integer) as Order

        ...return Order

    End Function

End Class

entonces tengo clases de controlador (recientemente implementé este estilo)

Public Class OrderController

    Private Shared _orderDAL as new OrderDAL

    Public Shared Function GetOrder(id) As Order

        Return _orderDAL.GetOrder(id)

    End Function

End Class

Luego en mi aplicación

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

Originalmente descubrí que con la Clase compartida no tenía que seguir creando una nueva instancia del DAL cada vez que necesitaba recuperar datos

Dim _orderDAL as New OrderDal

_orderDAL.GetOrder(1234)

.....

¿Cuál es tu opinión?

Gracias

Answer 1

He usado su solución en el pasado, y el único problema que enfrenté es que "Compartido" o "estático" Los métodos no son compatibles con la herencia. Cuando su aplicación crezca, es muy posible que necesite admitir diferentes tipos de "OrderControllers".

La forma estable de soportar diferentes OrderControllers sería, en teoría, crear una fábrica:

OrderControllerFactory.ConfiguredOrderController().GetOrder(42);

El problema aquí es: ¿qué tipo devuelve " ConfiguredOrderController () " ;? Porque debe tener el estático "GetOrder (int id)" método - y los métodos estáticos no son compatibles con la herencia o las interfaces. La solución a esto es no usar métodos estáticos en la clase OrderController.

public interface IOrderController
{
    Order GetOrder(int Id)
}

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

y

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

Por lo tanto, probablemente estará mejor utilizando métodos no estáticos para el controlador.

Answer 2

Creo que hay varias alternativas enumeradas en este excelente libro: Patrones de Enterprise Application Architecture . Algunos patrones que pueden ser de su interés:

• Registro activo
• Table Data Gateway
• Row Data Gateway
• Data Mapper

Answer 3

Bueno, su aplicación no debería crear instancias de versiones separadas de la capa de acceso a datos, por lo que tiene eso bajo control. Sin embargo, el código Psuedo que publicaste es realmente difícil de leer.

La pregunta es, ¿cuál es su capa de acceso a datos y cuánto hay? Eso va a dictar una buena parte de lo que haces. Si persiste en un archivo, creo que lo que ha escrito está bien, y si necesita compartirlo con otros controladores en su sistema, es posible envolver el elemento en un singelton (estremecimiento).

Si realmente está procesando pedidos y persistiendo en una base de datos, personalmente creo que es hora de mirar un ORM. Estos paquetes manejarán los aspectos de CRUM por usted y reducirán la cantidad de elementos que debe mantener.

Mis $ .02, y me reservo el derecho de revisar mi respuesta una vez que vea un mejor ejemplo.

Answer 4

No puedo hablar con los detalles de VB porque no soy un desarrollador de VB, pero:

Lo que está haciendo es una buena práctica bien establecida, que separa la capa GUI / presentación de la capa de datos. Incluir código de aplicación real en los métodos de evento de GUI es una mala práctica (lamentablemente también bien establecida).

Su clase de controlador se parece al patrón de puente , que también es una buena idea si ambas capas deben poder cambiar su forma sin que el otro lo sepa.

¡Adelante!

Answer 5

Es una buena práctica, especialmente cuando llega a un punto en el que el Controlador tendrá que hacer más que una simple delegación al DAL subyacente.