I'm not sure if this is the right forum for this, but...

We're building .NET App using WinForms, Web Services, a middle-tier, and SQL Server. We have four primary moodules, each consisting of about 15 screens, and about 30 sets of functions per module.

There's some debate within our development group regarding levels of abstraction in the middle-tier. In a nutshell, here is what we have:

Any time the WinForm needs something (basically, to retrieve data or to push data back to SQL), it calls a general method in the Web Service called 'ChannelRequest'. The WinForm passes to 'ChannelRequest' the name of the module being used, and the name of the function being requested. It may also pass user selections, user entries, etc.

ChannelRequest is the lone method in the Web Service. It passes the information sent from the WinForm to a main application manager.

The application manager takes the request, and determines which module is being called. It passes the information originally sent from the WinForm to the module manager.

The module manager takes the request, and determines which method within that module is being requested. It passes any local selections from the Winform to that function (that function is usually where the bulk of the method code/business logic resides).

And when that method actually communicates with SQL, it does so by way of a data 'broker' which handles all the talking with the database server.

While I realize this is the 'right' way to do things, I have a concern that we're talking about 4-5 function calls just to get to the actual logic. That 'seems' to me to be excessive overhead. And we're talking about thousands upon thousands of hits a day. Is this a good design, or do the levels of abstraction need to be reduced?

(And by the way, all parameters passed back and forth to different methods is done by way of populating a dataset. We seldom pass any strings as parameters.)

Thanks,
Kevin