Website, DB, & Software Developers

What I've experienced is that trying to put business rules and other application logic into .Net classes doesn't work out very well -- with the best intentions, it doesn't fit smoothly and you always end up with big pieces hanging out. The business logic keeps wanting to stick closer to the database than to the .Net app. So IMO it's better to just take the approach from the beginning that most of it belongs in stored procedures, not in .Net classes.

As for a WCF interface, first ask yourself if there's a real need for splitting the app over two servers. If not, using it is probably just overengineering, and adding an unnecessary additional source of potential problems. Don't worry too much about the risk of discovering later that you wanted it after all -- splitting an assembly off into a service isn't a big deal, should it become necessary. So I'd say don't be premature about it.