Here's some things to get you thinking, they're in no particular order of importance... 1) Something fairly important and often overlooked when moving from 2 tier (ie client accessing database directly) to n tier (ie client accesses servers that access database) models is that you cant just change your database calls to server calls and expect to have any performance. So, say you need to get a list of customer orders. In a 2 tier system the client might make call to the database to get a list of customers and then a call per customer to get each customer's orders, or whatever. This is a less than ideal design for 2 tier as you can most probably move a lot of the work into the db anyway, but for n tier it's a nightmare. You want one call from client to server that retrieves all of the information that you need in one hit... 2) Don't retain state in the server. Stateless is the way to go. Each call from the client should assume that the server has just been restarted and knows nothing about the client prior to the call. This helps with scaling out to server farms at a later date. 3) If you're doing 2 then you cant do this anyway, but, don't hold resources across client calls. So no server interfaces that look like LockThingy(), DoWorkWithMyThingy(), UnlockThingy()... 4) Try not to write your own middleware. There's plenty out there that works, just pick something. Simple TCP/IP byte stream command parsing is fine, but if you need complex load balancing or fail over then chances are someone else has already done it better than you can do it... 5) Only pull data to the client that you actually need. So, that list control that you want to populate with 200000 rows, so that the client can pick 1, just say no... 6) Speed up the server with caches if necessary (though you should trust your database first and only add cacheing to the server if your profiling shows that it's needed). Note this doesnt contradict 2 as the client shouldnt need to know or expect the caching to be there, things are just slightly faster if it is. 7) Pick appropriate technology. C++, VB, COM+, OLEDB? Java, CORBA, JDBC? Remember the client doesnt have to use the same technology as the server. Remember that some things work better on a corporate intranet than on the internet... 8) Get a thin thread of functionality from front to back as soon as possible. Dont spend 2 months writing a cool gui (because you know how to do that bit) and leave the connectivity and server till the end (because it cant be that hard). Get a dialog
