Hi Michael,

Just to expand on Jim reply, You could have Strategy objects for returning converted data to business objects depending on the front-end (to cover what you specify in your 4th Layer). This could go in the middle-tier if required.

The classes would still be required though. Its just a way to look at the model.

>Actually, after giving it some more thought a 5-tier design could be incredibly flexible. The implimentation might be a bit tricky, however. If you had an app that you wanted to be completly divorced of both the front end and the back end a 5-tier design would seem to be the way to go. You would need the following classes: Front end (UI) class, front end data conversion class, bizobj class, back end data conversion class, and back end. The front end class would send-receive data from/to the front end data conversion class. The front end data conversion class would then pass the data on to the bizobj. Since a data conversion class resides between the UI and the bizobj, the bizobj would always recieve the same data format regardless of the FE being used. The bizobj would apply any business rules necessary and pass it on back to the back end data conversion class. The data would be formatted for the back end and passed on.
>
>With this setup any front end could be used as well as any back end. From the bizobj's point of view it wouldn't matter. This design could also be easily extended to include new front ends or back ends as needed. It would simply be a matter of designing new data convesion classes.
>
>Like I said, while this looks like a great idea in theory I can imagine the design could get quite complex. I guess there is a point at which you design your applications to be too flexible...
>
>
>>Actually, you make a good case for more than 3 tiers. You could have your business tier always return data in a cursor or recordset of some kind. The web application could then have an additional tier that renders the data into HTML. For example, your presentation tier is a browser, the "formatting" tier is your web server running ASP, the business tier is a COM component, and the data tier is SQL Server. You can segment it even more by creating an additional tier that's just a "data access" tier. This sits between the database and the business rules object. It would just handle basic data requests (give me these records, insert this record, etc.). It would allow you to support multiple back-ends more easily.
>>
>>>Hmm..would an N-Tier design that had 3 layers be about the same as a 3-tier design? N-Tier indicates any number of tiers...but why would you need more than 3? Just wondering what the conceptual differences are here.
>>>
>>>If you were designing a system that could be accessed through a VFP, Visual C++, or HTML frontend and local or remote data on the back-end this would be a good candidate for an n-tier design, no? In this example I suppose you would create an active-x server for your middle tier containing your bizobjs which would then request the data from the backend and serve it up to the frontend. You would perhaps have bizobj subclasses specific to the type of data you need to return. For example you would need a bizCustomer bizobj that could return data to a VFP f.e and another one that could format for HTML, etc. Am I on target at all here?
>>>
>>>Well, enough rambling for one post.
>>>
>>>Cheers!
>>>
>>>>>I do have one question: Do you use data behavior classes? If so, wouldn't that be the object that decides how to get the next record?
>>>>
>>>>Michael,
>>>>
>>>>In an N-Tier system the bizobj is the data behavior object. I may use a form class that has a GoNext emthod, but if the form is using a bizobj that method will simply delegate to the bizobj.
>>>>
>>>>As Steve Black has said, the ultimate value of business logic objects is not a forgone conclusion, sometimes they may be the best thing ever done and at other times they will be in your way.
>>>>
>>>>I find them best suited for the situation where multiple divergent interfaces are required to access the same data. In this case they provide a level of insulation between the data and the interfaces where rule enforcement can be done without requiring the code for it be repeated in each and every interface.
>>>>
>>>>I still do rule enforcement in the interface because my philosophy is that the user should be assisted to get thing right before any other layer of the system rejects the data.
>>>>
>>>>If you have ever created a field validation rule in a VFP database, then bound a contrl to that field and written code in the contrl's Valid event, you will see that the database rule fires before the valid event of the control. With a bizobj between the control and the database this does not happen and your control's valid event can assist the user in getting the data right before it is submitted to the database.