Collection Opinion 2

[jfrost10]

Hey guys,

First off, sorry for not being around teh forum much anymore (heh, well assuming anyone noticed ). I was let go from my job over Christmas, and until I get anotehr gig I'm stuck with WinXP home (no web server = no asp.net dev).

Anyway, I'd like your opinion on an architectual aspect of web development. Previously, when I developed, I'd avoid using collection classes to hold reams of objects in memory on the web server. Instead, I'd use the dataset/datatable objects as my collection, and only retrieve data relevent to a particular selection from those (i.e. a data table has an ID field, and a name field. The user selects the name they want more info on, and the system retrieves the requested object based on the ID).

I'm just curious on how you all are handling this. Are you doing something similar to the above, are you using the traditional object collection method where one collection object holds reams of objects within, or another method?

Thanks!

D

 

[Zarcom]

When I started .Net development I made my own classes that held data about that certain object. However, like you I have switched over to useing strongly typed dataset classes to do this. I find that it is easier to code with and seems to be one less layer. That'l do donkey, that'l do
Mark
If you are unsure of forum etiquette check here faq796-2540

 

[link9]

The only time I use collections is when I implement a completely custom collection class, where I plan to bind it directly to a control, much like you would a datatable/dataset to a datagrid/datalist (which by the way, if you haven't experimented with it, is an extremely useful technique).

Otherwise I'd steer away from collections due to the overhead involved.

The answer to getting answered -- faq855-2992

 

[jfrost10]

Thanks for the replies guys. The question was kind of selfish of me (heh, I've heard my former boss is converting hte entire object model I did to use collection classes...I don't think he's thought through the overhead, as you both mentioned. More of a "I knew I was right" thing than anything else). But its good to know that I was on the right track avoiding collections in general.

D

 

[Craig0201]

Opposite opinion....

I would use collections at the business level. I try to abstract as much as possible and isolate the levels between my objects. So my layers run along the lines of

1) DB
2) DB access layer (Web service, most likely)
3) Collection of business objects
4) Individual business objects
5) FE

Sure you all know the principles of abstraction but say I change how my data returns, I only need to change my collection, not my object.

I do appreciate that there is extra overhead but abstraction and the maintainence ease overcomes that for me.

But the bottom line is.....watch the bottom line....if you spend more cash in developing collections than what you save, don't do it! I believe that I will in the long run but it don't mean you will!

Craig

 

[jfrost10]

Hey Craig,

Just curious about how that works though. So your objects themselves don't hve the ability to communicate with the data access layer, but the collection object itself does? So does that mean that if you're making changes to one object, you have to always have the business object AND a collection object created?

Not trying to be difficult, just curious about this method (I've only ever seen collections holding objects, not acting as a layer between objects and data access)

D'Arcy

 

[Craig0201]

D,

Maybe didn't write that correctly.

I do try to have collections wherever possible, including where only one object exists. I assume that there may be more than one (unless I know there will only be one).

The Update method is on the collection. An analogy is the datatable. The update method is on the datatable, not the datarow. So the collection controls the update. Why do I do it that way? Responsibility splitting. The class is responsible for processing the business object, the collection is responsible for communicating between data access and the business object and the data layer for actually talking to the db. I find the more I split responsibilities so that the class only does what it needs to, the easier it is.

Does that make sense?

Craig

 

[jfrost10]

Hey C,

Yeah, I understand more clearly now how your approach works. So your business objects are there just as a container for data and nothing else then?

D

 

[Craig0201]

D,

No. They do their own processing. So an order line object would be responsible for checking that the goods were in stock.

I guess there is a blurring of how it does things and maybe i'm not describing it well.

Think the best way of saying it is that the collections talk to the DB for inserts, updates and deletes; the objects are responsible selects that are only needed internally.

So back to my order line object, it can find out if it can be done but it doesn't place itself.

Better explained??? I hope so!! Blimey, whoever would have guessed my previous profession was a teacher!

Craig

 

[link9]

Craig,

I think that's a very nice model. Everything is so blazing fast in .NET anyway, I would have to agree with you that the form of the model can trump the function in this case.

I doubt you would ever notice the difference otherwise, and the distinct levels of abstraction are a huge plus.

Do you ever play with binding those collections to databound objects? I'd say that given these two big advantages, you just might have won me over.

Thanks for the input!
paul

The answer to getting answered -- faq855-2992

 

[Craig0201]

Paul,

That's my feelings too re: .NET. PCs are fast these days. OO isn't optimised code. It's about maximising the ROI on my time.

I haven't tried it (I mostly do back end, my colleague does GUI) but I know exactly how I would do it. I would implement the same interface used by the databound objects in my collection (IEnumerable?) and use that to bind from.

If I could recommend a couple of books that have really influenced my style (strange thought that programs have style!)....

UML Distilled and Analysis Patterns by Martin Fowler.

Now we've got (as full as possible) true OO, I think us VB programmers are obliged to use the models and patterns as much as possible! Will make us better programmers.....know I certainly am.....

Craig

 

[jfrost10]

Hey Craig,

thanks for the explanation and the book suggestion. I've been looking for a good one on design patterns for a while, might just check that one out.

D

 

[Craig0201]

Paul,

Was intrigued so I looked into it. It is IEnumerable that makes a collection bindable. You need to implement only one method, GetEnumerator. This returns a class implementing the IEnumerator interface. This itself has 1 property Current and 2 methods, MoveNext and Reset.

Doesn't look that hard to do at all.

Craig

 

[link9]

No, it's not that hard. I have a link to an example in our tidbits thread, and a FAQ is in the works for an example specifically for this forum.

I'm thinking of taking a thread-post approach, and putting together an example for us.

Currently, I'm working on a content management system for a news station, and so they have stories. Each story has a headline, a brief, a story, a picture, etc....

I took the collection approach and can bind my stories collection directly to a datalist for display. It's so easy and beautiful, it should be illegal.

-paul

The answer to getting answered -- faq855-2992

 

[Craig0201]

Paul,

Sounds excellent. Will have a look in the thread.

Craig