What's the common way for OOP Pattern design (Data Access)

Question

Hi, Originally there was the DAL object which my BO's called for info and then passed to UI. Then I started noticing reduced code in UI and there were Controller classes. What's the decent recomendation.

I currently structure mine

Public Class OrderDAL

    Private _id Integer
    Private _order as Order

    Public Function GetOrder(id as Integer) as Order

        ...return Order

    End Function

End Class

then I have controller classes (recently implemented this 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

Then in my 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

I originally found that with the Shared Class I didn't have to keep creating a new instance of the DAL whenever I need to fetch data

Dim _orderDAL as New OrderDal

_orderDAL.GetOrder(1234)

.....

What's your take?

Thanks

Answer 1

Well your application shouldn't be instantiating seperate versions of the data acces layer, so you have that under control. The Psuedo code you posted is really hard to read though.

The question is, what is your data access layer, and how much is there? That's going to dictate a good bit of what you do. If your persiting to a file then I think what you have written is fine, and if you need to share it with other controllers in your system, it's possible to wrap the item into a singelton(shudder).

If you really are doing order processing and persisting back to a database, I personaly think it's time to look at an ORM. These packages will handle the CRUM aspects for you and reduce the number of items that you have to maintain.

My $.02, and I reserve the right to revise my answer once I see a better example.

Answer 2

I think there are several alternatives listed in this excellent book: Patterns of Enterprise Application Architecture. Some patterns that may be of interest to you:

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

Answer 3

Hi, Sorry about the coding. Yes, my app is based in order procedding and reporting. All my data access Insert,Update,Delete,Fetch is in the DALS. From my front end apps (Winforms), I access the DALs via the Controller classes, these classes also does a few other things like, if a product was not returned, it posts a message to a specific form.

The thing is, are the controller classes really necessary? Originally I'd bundled all my worker codes (my naming) right on to each forms, however, some of the other forms had repetitive calls, so with the Controller classes and shared functions and subs, I was able to remove this coding horror,but it's kind of getting out of control.

Thanks

Answer 4

I can't speak to the VB details because I'm not a VB developer, but:

What you are doing is a well-established good practice, separating the GUI/presentation layer from the data layer. Including real application code in GUI event methods is a (sadly also well-established) bad practice.

Your controller class resembles the bridge pattern which is also a good idea if both layers shall be able to change their form without the other knowing about it.

Go ahead!

Answer 5

Its a good practice -- especially when you get to a point where the Controller will need to do more than simple delegation to the underlying DAL.

Answer 6

I've used your solution in the past, and the only problem I faced is that "Shared" or "static" methods don't support inheritance. When your application grows, you might very well need to support different types of "OrderControllers".

The estabilished way of supporting different OrderControllers would be, in theory, to create a factory:

OrderControllerFactory.ConfiguredOrderController().GetOrder(42);

The problem here is: what type is returned by "ConfiguredOrderController()"? Because it must have the static "GetOrder(int id)" method -- and static methods are not supported by inheritance or interfaces. The way around this is not to use static methods in the OrderController class.

public interface IOrderController
{
    Order GetOrder(int Id)
}

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

and

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

Hence, you will probably be better off by using non-static methods for the controller.