What's the common way for OOP Pattern design (Data Access)
-
02-07-2019 - |
Question
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
Solution
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.
OTHER TIPS
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:
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.
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!
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.