We've blogged before back in 2010, and again in 2012 about possible VS project structures for developing in Umbraco, however, nowadays we use what we think is a pretty simple structure. The strange thing is, when we tell other developers how we work, we often get some funny looks/comments, mainly because we decide to take a pragmatic approach that works for us, rather than follow "best practise".
Basically, we use one solitary Visual Studio "Website" project to house the whole shibbang (ok, we may move things out to separate DLL's if it warrants it, but this is a special case for us, not the norm). Notice that we said "Website" project not "Web Application" project, this is what usually gets people confused.
So why do we use websites projects?...simplicity!
By using website projects, all assets are available to us at all times. We don't have to do any clever pre build copying commands, or remember to include a file in the project if we copy anything over. What's on disk, is what's in our project.
But where does the code go?...the App_Code folder
By working direct in the App_Code folder we don't have to bother compiling, instead we let IIS Express take care of that when we reload the browser. Heck, you are going to have to do an app pool recycle anyway, so what harm's one itty-bitty compile going to add? Of course we keep the folder well organised and structured, but we just don't break everything out into a separate DLL's.
Don't you loose compile time checks?...yup
But we'll soon find out when we refresh the browser and get a pretty little YSOD telling us exactly where the error is :) We can still use breakpoints and debug the IIS worker process, we just find the errors in the browser, rather than in VS.
Aren't you worried someone will gain access to your server and change your code?...nope
If someone gets access to your server that shouldn't, then you've probably got bigger things to worry about. We find a daily backup is a good enough fallback to rollback a site should anything untoward happen.
For us, having the source code on the server is actually a benefit. Ever been on holiday and had a client ringing you that their site is down? Most people's response is "Sorry, I don't have my dev tools with me, I'll have to get back to you in a week", whereas for us, we just jump on any PC, fire up RDP and make the change direct on the server (promptly followed by an email to ourselves to remember to resync when we get home :))
At the end of the day, we are in the business of making websites. Not missile defence software or space shuttle guidance systems, every day, in the wild, websites.
Obviously, the way we work isn't going to suite everyone, but for us Visual Studio, Umbraco and everything else we use is just a tool for getting the job done. If deviating from suggested "best practise" enables us to simplify the process of building website whilst still maintaining flexibility and delivering a quality finished project to our end clients on time that is easy to maintain, then we are going to take it.
Depending on how well this post goes down, maybe we'll write another post on why we write logic in our MVC views :) [Hint: Pretty much similar reasons]