Why would they access data like this??? AKA Code Analysis/Review

Question

User1465848623 posted

Hello all,

I am looking for some serious analysis / criticism for a system design I have been asked (why I was hired) to help fix. The way it works is thus:

User logs in and a page is displayed with say items to buy. Pretty straight forward. The part I am confused with is in the middle where they interact with the database. Rather than say creating a Linq or ADO connection, executing a stored procedure, getting a recordset, and handling they instead create an object, pass in parameters they want, and then the object returns classes with member variables, properties, and arrays containing the data.

So instead of getting a recordset I have to build rows for a grid drilling into the object for each piece of the row.
DataGridRowA = obj_ABC.subObj_DEF[0].subSubObj_GHI[0].Name;

For my sanity I am using reflection and getting all the members and their values into recordsets to work with but I really want to know if the developer before me was a Jedi Master playing on a 3 level chessboard and I am way behind or if this was his personal waterloo??


Now I want to make an earnest effort at understanding what might have been the idea behind this approach (Original developer no longer here) but for the life of me can NOT figure out why they would do it this way.

Your CONSTRUCTIVE thoughts or opinions would be greatly appreciated
Thank You
JB 

Answer 1

User-952121411 posted

I have question that may have a bearing on the explanation given - you mentioned the word 'Recordset' and 'DataGrid' a few times; is this a legacy VB6 application, or did you mean to say something like DataSet and GridView?

If you meant an ADO.NET object then I understand.  However, passing objects around, especially lists of objects (Generics .NET Framework 2.0+) can be quite powerful, and can be directly bound to controls as the DataSource.  There would be no need to drill down to each value and manually bind it.  However, based on the notation you are giving and some of the terminology used I have a feeling the is not a .NET app, or a .NET app attempting to use classic ADO.  Can you confirm or deny this please?

Thank you,

Answer 2

User1465848623 posted

Yes sloppy terminology.  Built in .Net 1.1 (not sure internals design as all I have is a reference to a DLL to put in bin folder) and yes many controls on the web page but how can I bind then? The control would bind to object abc which has fields 1 2 3 and 4. Of those #4 is an array to more objects with their own fields and more arrays? So my control bound at the top level would or would not have access to sub - sub - sub arrays?

 

Thanks

JB

Answer 3

User-952121411 posted

The control would bind to object abc which has fields 1 2 3 and 4. Of those #4 is an array to more objects with their own fields and more arrays? So my control bound at the top level would or would not have access to sub - sub - sub arrays?

 

Yes the further explanation help make a clearer picture.  Typically objects are always preferred to individual data types (see this thread for a current discussion on this topic: http://forums.asp.net/p/1528205/3693214.aspx), and they may have been the thinking at the time that .dll was designed.  However, in the manner you explained it was designed, in addition to it being the .NET Framework 1.1 you are probably stuck with drilling down and manually binding the controls via each property as you have explained.

Once the .NET Framework 2.0 came along, things like the Object Data Source control allowed the developer to wire up a business object and dictate which fields and elements were bound where in the control (i.e. a GridView control with several columns, each mapping to a property on an object).  Also, one could use a List(of MyClass) to manually bind directly to a control which works well too.

If you are stuck with a .dll that you did not design and can not update it to be built more along the lines of current technologies, then one recommendation I have is to place a layer or functionality between that old .dll and your UI or business logic layer, that remaps the object and 'sub properties and objects' into a more meaningful and useful object to be passed around and possibly persisted upwards in the application.

In this manner, you isolate that old .dll to a set place, and add a wrapper to map the data into a better object to be used in a more updated and sensible manner.  If you are not stuck with the old .dll and have the source, then you can make sense of what it was doing and rewrite it into a better structure that your new team sees usable.

If you have not looked at using the List(T) class in .NET, take a look to the following for some more information:

.NET Object Collections Using Generics 101:

http://allen-conway-dotnet.blogspot.com/2009/11/net-object-collections-using-generics.html

Hope this helps!