Cuál es la forma común para el diseño del modelo de programación orientada a objetos (Data Access)

Question

Originalmente era el objeto dal que llama de mi BO para recibir información y luego se pasa a la interfaz de usuario. Entonces empecé a notar código reducido en la interfaz de usuario y había clases de controlador. ¿Cuál es la recomendación decente?

que actualmente la estructura de la mina

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 implementado 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 solicitud

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 encontraron que con la La clase compartida I no tiene que seguir creando una nueva instancia de DAL cada vez que eed para buscar datos

Dim _orderDAL as New OrderDal 

_orderDAL.GetOrder(1234) 

..... 

¿Cuál es su opinión?

Gracias

Answer 1

He utilizado su solución en el pasado, y el único problema al que me enfrenté es que los métodos "Compartidos" o "estáticos" no son compatibles con la herencia. Cuando su aplicación crece, es posible que necesite soportar diferentes tipos de "OrderControllers".

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

OrderControllerFactory.ConfiguredOrderController().GetOrder(42); 

El problema aquí es: ¿qué tipo devuelto por "ConfiguredOrderController()"? Porque debe tener el método estático "GetOrder (int id)", y los métodos estáticos no son compatibles con la herencia o las interfaces. La forma de evitar esto es utilizar 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, es probable que estarán mejor mediante el uso de métodos no estáticos para el controlador.

Answer 2

bien su aplicación no debe ser instanciando versiones separadas de los datos acces capa, por lo que tiene que controlar. Sin embargo, el código de Psuedo que publicó 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 está persistiendo en un archivo, entonces 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 (escalofrío).

Si realmente está haciendo el procesamiento de pedidos y la persistencia de nuevo a una base de datos, yo personalmente creo que es hora de mirar a un ORM. Estos paquetes manejarán los aspectos CRUM por usted y reducirán la cantidad de artículos que debe mantener.

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

Answer 3

creo que hay varias alternativas que se listan en este excelente libro: Patterns of Enterprise Application Architecture. Algunos patrones que pueden ser de su interés:

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

Answer 4

que no se puede hablar de los detalles VB porque yo no soy una VB desarrollador, pero:

Lo que está haciendo es un pozo-es Buena práctica establecida, separando la capa de GUI/presentación de la capa de datos. Incluir el código de aplicación real en los métodos de eventos GUI es una mala práctica (lamentablemente también está bien establecida).

su clase controlador se asemeja a la bridge pattern que también es una buena idea si ambas capas deben ser capaces de 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 necesitará hacer algo más que una simple delegación en el DAL subyacente.