>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).

The advantage of your approach is that at some point you should be able to switch in a different "UI" (ie. WebUI or WebService) and not effect the "Business Facade" (what you are refering to as the "middle tier").

If you now split the "Business Rules" and "Data Access" out of this "Business Facade", then you will have a true "n-tier" application.