Question Object Creation, Binding and Management

[jediknight]

I had a general question regarding Object creation, Binding and management. Though this question might be better served in the Database Group, I think it is general enough to post right here since it is a more general question.

I've experiemented in the past with creating a Singleton Business Object to bind the properties to the controls on the form. The initial query from the data source is displayed on the form but further queries do are not displayed on the form even though they are displayed in the object. It is easy enough to remove binding entirely and simply assign the values from the properties to the controls and vice versa to maintain only one instance of the business object. I'm not entirely certain how that would effect validation.

When I am not trying to use a Singleton the object creation might look like this:

Public Class Customer
[INDENT]...(property definitions)[/INDENT]
Public Shared Function Create(ByVal id As Integer) As Customer
[INDENT]Dim cust As New Customer
Dim dt as New DataTable

dt = ExecuteTable(My.Resources.SP_RetrieveCustomerByID, id)

With dt.Rows(0)
[INDENT]cust.CustomerID = .Item("CustomerID")
cust.CustomerName = .Item("CustomerName")
cust.CustomerContact = .Item("CustomerContact")
cust.CustomerAddress = .Item("CustomerAddress")

...[/INDENT]
End With

Return cust
[/INDENT]End Function

I'm returning a new Customer Object for every query for the object binding to work properly. What is happening to the objects I am creating? When I call this function multiple times to perform additional queries does the binding object hold those somewhere so if a query is performed again it can reuse the object. What would the advantages of creating a Collection member be to manage these multiple creations?

 

[cjard]

First, I'd like to ask why you'd bother with this route? If you make a DataTable in your project then you have, effectively, created an object that is data bindable, and you can extend it with custom functions if you require.. And it is already a collection of the object being bound (actually the datarow)

If you can help me understand why you'd go to the effort of making a custom class Customer in the first place and then shooing data in and out of it, when you could just drop the Customer database table into a dataset, and end up with a device suitable for single or multiple instances of customer that can be conveniently populated from database data, I'll be better able to answer the question..

 

[jediknight]

Validation, flexible application design

I appreciate your response to my question. I'm designing the application to be flexible and adaptable, holding the business logic separate from the UI and data access so I can reuse the objects and the attached logic in other applications. I am not aware of extending functions in the datatable, does it provide for validation? Does it have full control of the data when a datatable it assigned directly as you specify? Can you drop it into mutiple applications seamless with all the business logic attached? Frankly, I don't really find it that much work and I really enjoy designing and implementing the framework. It allows me to change or add UI (WinForm, WPF or Web) or include various data providers SQL, ODBC, OLEDB that return varying objects (datareader, datatable). I had forgotten that the GC takes care of the objects but maybe I was really wondering whether it would be a good idea to use Dispose or just let the GC handle it? Thank you again for your friendly answer.

 

[cjard]

I'm all for modularity and code reuse; I spend a lot of time trying to get people to use datasets rather than put SQL code into their button click handlers..

Yes, using a Dataset makes for reusability and code encapsulation - you can easily drop that dataset into another app, or compile a DLL containing it and reference it in other palces - it becomes the data access layer abstraction, different databases are possible but uncommon..

I think i can count on one hand the number of times I've reused a data acces layer over the years. Every app has been different, data requirements different and the effort required to reuse an existing data layer rather than just tell visual studio what tables and procedures to link to and have it generate custom code there and then has never actually been worth it.. Of everything I've reused, data access layers have been the least reusable aspect

 

[jediknight]

I don't know how this has turned into a debate over programming styles/methodolgies vs. my question being: would it be a good idea to use dispose or just let the GC handle object removal.? At this point, I've talked myself into going with the GC since no unmanaged resources are being used.

Anyhow, if you are comfortable with the way you write your code GREAT! I'm not trying to convince you of anything. Nor am I trying to convince you that your efforts are a waste of time or my way is better. I only answered the question you asked which was why I was programming the way I was.

I read a book a few months ago: Professional Design Patterns in VB.NET: Building Adaptable Applications. Even though the book is somewhat dated (© 2002) I found many of the concepts discussed in the book useful. It doesn't cover the complete group of four patterns but it does discuss many of them including really good examples for building adaptable programs and code reuse (including the data access layer). You may want to check it out. The hardest part is getting through the first chapter of design patterns. After that it was the coolest thing I had ever seen...

 

[cjard]

Even though the book is 2002 .. You may want to check it out

2002 dates from the dark ages before Visual Studio could build high quality, reusable data access layers for me in a few seconds, so I understand why it might advocate building custom objects and pushing data in and out of them by wasting my days toiling away writing thousands of lines of code; it was how we did it back then.

If it's all the same to you, I'll pass on the time travelling opportunity but in answer to the first question you asked; nothing in that code fragment provides for caching and reuse of retrieved data. Every time the function is invoked a new customer is created. If there are no surviving references to the returned customer then it will be removed by the GC at some point and, from what is visible here, it would not require special treatment or implementing IDisposable