>>>>>>I would make GetShopOrderDetails static and call it with:
>>>>>>

>>>>>>dtShopOrder = ERP.GetShopOrderDetails(txtSerialNum.Text);
>>>>>>

>>>>>
>>>>>Why static? Isn't an instance the desired return value?
>>>>
>>>>Because you wouldn't need to instantiate ERP in order to call GetShopOrderDetails()
>>>>
>>>>This is one object less to create and one object less to garbage collect
>>>
>>>Thanks. That famous C trickery? ;-)
>>
>>trickery ? Not really, just efficiency
>
>Trickery was not the right word. What I meant was an obsession with performance that can make code hard to understand, its meaning unclear.
>
>Although C is famous for this (IMO), it is not unique. I remember when VFP first arrived and a lot of people were using Line as the parent class for non-visual classes because it was allegedly the most lightweight. Forget that a line is a GUI element with nothing whatsoever to do with MyWhateverNonVisualClass. Whoever reads or has to maintain the code is somehow supposed to understand that. I. Don't. Like. It. ;-)

I use Relation for the LightWeight class


>Some of the old timers here will remember a guy named Jeff Winchell. He was and probably still is a curmudgeon of the first rank. He irritated a lot of people, including me sometimes. But he said one thing that I have not forgotten and that has always guided my coding: "Write boring code." The look-ma-no-hands stuff may shave some cycles but is the trade-off in understanding worth it?

I do not think that this is about "look-ma-no-hands" but rather why add some cycles if you don't have to

I will always remember this ( http://msdn.microsoft.com/en-us/library/ms973852.aspx )

"I promise I will not ship slow code. Speed is a feature I care about. Every day I will pay attention to the performance of my code. I will regularly and methodically measure its speed and size. I will learn, build, or buy the tools I need to do this. It's my responsibility."