>>I have a complex application that I'm working on splitting up a bit, I'm a little way through but wanted to ask a question. My middle-tier has around 25 data-objects so far, all linked to a main application object.
>>
>>Now, what I want to know is if what I'm doing, is a good idea. Rather than create new instances of data-objects on the forms, I call a method in the (middle-tier) application object that returns a reference to the data-object, this way, if the object is updated by one form, it will always be reflected because it is a continuously running single instance.
>>
>>Is this good practice? Or is it better to create objects freshly?
>
>What you're doing is a "good thing" (in Martha speak), but you're not really creating a "middle tier"; you're separating the "UI" from the "code behind" (in .NET speak).
>
>You are still maintaining "state information" (in the code behind), so in effect these components are still part of the front-end. If it was a true "middle-tier" it would have no memory and would be scalable (ie. deployable on and across multiple machines).

Well, the middle-tier has it's own application object, not linked to the front-end. The front-end creates this app object and uses that as the central "hub" for all child data-objects. But even if the middle is maintaining "state information", it's only data-related state, nothing to do with the front-end, this information is only used by the middle data-objects.

What should I do then, to completely seperate the front from the middle, I assumed I was already doing that, but obviously not.

Thanks
Kev

PS The Data-Tier will one day become SQL-Server, and there will be more seperation of the middle & Data, for now, it's one at a time :)