SharePoint best practices with solutions

I was wondering if I could get some thoughts on what the best practices are for sharepoint webparts and Visual Studio structure. What I mean by this is, I have several sharepoint form application projects, all have several tabs or pages within their project (admin page, view records page etc) and are all under the same grand "intranet" company project. I see a lot of tutorials and other sites that seem to make all their Webparts in seperate solutions and what not. I have three questions:

1.) Should each "part" of the form project even if it's another page be in different webparts OR of the same project? I would think the latter, because if it wa开发者_如何学编程s in another project, it would be difficult to get control of during runtime.

2.) Should other forms of the same master intranet project, but in their own Visual Studio projects be in the same solution? or different ones.

3.) Class Libraries... Are they done the same way as WPF or ASP.net?

Well it really depends on your requirements. Most of the time i use the WebPart just as a wrapper to load my UserControls (which are in a different project but in the same solution) dynamically. If you need something more "static" i'd recommend using Application Page's instead of WebPart's.

I'll try it to explain it with an example:

Lets say you want to create a solution that helps your project managers do their job (haha :-). You'd call this app something like "PM App". It consists out of 3 parts: Issue Tracker, Time Tracker and a Reporting App.

First step, obviously, is creating a blank solution named "PM App". As all 3 parts of the solution have somethings in common, for example a logger component or a DataAccessLayer, you'll create a new project named "Common".

Then it really depends on your solution design. Lets say we go for a WebPart / UserControl solution. You create a new project named "SP PM" which is a SharePoint project (actually, i have yet to find a appropriate name for this project). Then you create a WebPart for each part of your solution (IssueTrackerWebPart etc...). Now, if you only have 1 UserControl per WebPart, easy peasy. The WebPart basically acts as a wrapper for your UserControls.

If you (want to) have multiple UserControls, it gets quite tricky. I always end up creating a new ASP.NET WebApplication project named "UserControls" and add my UserControls there. The problem with doing it this way is referencing the UserControls in your "SP PM" project. Referencing the dll's is no problem, referencing the .ascx files on the other hand, is.

What i do is, copy the .ascx file(s) from my "UserControls" project to my "SP PM" project with a post-built script. I know this is definitely not the best solution, however i've talked to many other devs about this issue, but nobody has found a better solution until now.

This is a really tough issue in the SharePoint context (as in any other actually), and there aren't any Best Practices as far as i know. The best thing to do is sit together with your fellow developers, and ask them how they would create the solution/project structure and then find a good middle way.

tl;dr no "generic" way - really depends on your requirements.

I quickly put the solution togther how i think it should look:

Hope this makes any sense to you, and feel free to ask if you have any further questions. Also i'd like to hear some opinions about how other people approach these issues :-)