随着时间的推移，我维护的代码库呈指数级增长。我们有各种不同的实用程序类，webparts，事件接收器，控制台应用程序等。
通常，每个webpart都位于一个单独的DLL中（每个Web部件一个解决方案和一个项目）。我们的实用程序类也在很大程度上分离成它们各自独立的DLL（这包括任何专门的列表访问类，它们在DLL中与它们的bean组合在一起）。这导致了大量的解决方案变得更难以维护（将每个解决方案升级到Visual Studio 2008，或者只是试图找出DLL引用的迷宫）。
随着我对SharePoint Guidance的发现，我正在重新评估我们当前的代码结构。例如，看起来他们建议将所有专门的列表访问类组合到一个Repository中（到目前为止，我们完全相反，根据代码的“解决方案”将它们分成DLL）。
问题：我应该如何组织代码？您如何确定解决方案与项目vs文件夹或命名空间中的内容之间的关系？每个Web部件有一个解决方案吗？
答案 0 :(得分：0)
我通常按功能组织代码。假设我有一个外联网项目和一些内部网webparts的代码，我将它分成一个Extranet和一个Intranet项目，并将不同类别的代码（事件接收器，timerjobs，webparts等）分成不同的命名空间。 这样，如果我愿意的话，我可以将（子）功能集部署到不同的农场，当编辑代码时，我得到了在同一个地方彼此依赖的所有东西：）