• I have worked on several n-tier apps and the logic has always ended up where it makes the most sense.  Everyone tries to keep it in the middle-tier, but often for performance reasons it ends up in a stored procedure or on the client side before it is posted to the server especially when running apps over the internet where latency is an issue.

    I would guess at this point MS would rather you just shove it in the DB.  Mainly because once it is there, you are tied to SQL Server.  As a developer, middle tier is usually best because it gives you long term flexibility.  However, design needs often push logic into places where we would rather they not be. 

    I wouldn't be suprised in the future if business objects move around between systems (database, app servers, etc) based on performance and other indicators.  Will a developer really care where something runs when he accesses the XYZ object on a server from the client.  It would be nice to setup a machine or machines as a business cluster and let the OS figure out the most optimal place to run business objects.  Sure would give a lot more power to grid computing.  Have a performance problem server side?  Slap another server in, run a quick config to add it to the grid and database/business tier performance would go up universally.  It never is that easy, but who knows what the future will bring.