Kevin,

>The differences in views really boil down to the # of levels of abstraction in setting up business 'classes'. We have one developer who actually wants to 'mirror' every winform and control with corresponding logic in the middle tier.
>
>My preference is to identify all pieces of business functionality/requirements, and set up methods and properties accordingly. (For instance, if saving a financial transaction involves 7 steps, then set up 7 methods in the middle layer). I do have a general concern about setting up so many levels of abstraction that excessive overhead is introduced.

Ah, the intricacies of object-modeling! First of all, hopefully you're using the UML and some kind of modeling tool such as Rational Rose, Visio, or Visual UML. When you're creating monolithic applications, you'll find that these tools are unnecessary (although these days you really *shouldn't* be creating monolithic applications!). But once you start creating n-tier applications, you'll find them indispensable.

The concept of having business objects mirror winform and controls is definitely not a good way to go! Your business objects should be able to work properly regardless of the user interface...what happens if you want to use your business objects from both a Windows Forms and Web Forms application? Even with the advances in Web Forms, you're still going to have a somewhat different user interface between a Windows Forms and Web Forms app, so trying to tie business objects to the UI is definitely not a good idea. In reality, your business objects are typically created before you create your user interface.

Without looking at your specific application, I can only give you high level suggestions, but here we go...

You should typically create a business object for each of your main database tables. For example, if you have an Orders table, create an Orders business object. If you have an Inventory table, create an Inventory business object. Each business object typically represents a real-world entity. When you think about it, this is often true of your data tables. Each table represents the attributes of a real-world entity...a Customer in the real world has attributes such as Name, e-mail address, phone, etc, and you add fields to the Customer table that represent these attributes. Business objects take this a step further by representing the behavior of a real-world entity. All of the application logic that has something to do with Customers (adding, deleeting, editing, calculations, etc.) should go into the Customer business object. For a well-designed, well-balanced load of responsibilities, Customer business objects should manipulate data in the Customer table--Inventory objects should manipulate data in the Inventory table, and so on.

Now back to the "seven methods" question. Typically, if there are seven different steps in a process, you can create seven different corresponding methods. These methods may actually be located on different business objects--depending on which data is affected on the back end. This allows the individual methods to be called separately (if that makes sense) and allows you to create subclasses of your business objects in which you can override the behavior of one or more methods.

Your initial reaction might be to add code to your user interface to call each of these seven methods. However, the order in which these methods are called falls under the category of "business logic". If you call these seven methods in the Windows Forms UI, when/if you create a corresponding Web Forms application, you'll have to add the same seven calls to the Web Forms UI. It's much better to encapsulate these calls in an Event object. An Event object can be used to instantiate the necessary business objects (if they're not already instantiated) and contain a single method such as "ExecuteEvent" that makes the necessary calls to each object. With this architecture, in either the Windows Forms or Web Forms application you have a single object you can instantiate, and a single method to call to execute the entire event.

In the .NET and VFP classes I teach, we actually go through this exercise and I can tell you it's one of the most challenging aspects of n-tier architecture.

Hope this helps!

Regards,