在你的solution里面到底有多少projects? 小型软件公司如何更快的建立自己的Framework.

看到这样一个问题，低头看看你的solution里面，有多少个projects？

这个问题的答案可能是25个，45个，50个，还有可能更多；同时还会有人抱怨说：我的电脑太慢了！！我要同时编译太多的projects。然后大家开始需要更多的内存，更好的电脑。但是问题是我们真的需要这么多内存和那么强大的电脑来编译我们的程序吗？如果你的公司有一个膨大的Framework，几乎所有的项目都要引用5个以上的Framework，这就意味这你的项目还没有开始，你就已经有5个projects需要编译，如果再把自动生成的程序代码，3层结构考虑进去，那么十几个projects将是标准的项目装备。

对于直接引用源代码的方式（project reference），其实我一直都不太赞同，网上也有很多关于这个问题的讨论。当初使用这样的结构主要的考虑是为了程序员更加便捷的对framework进行扩充，其实每个开发人员都一样，如果能很快的解决问题，那么大家都不愿花费时间来编写可从用的代码。但是对于中小型的软件公司来说，我们没有多资金来专门雇人维护自己的framework，但是如果没有这样的东西，那么我们的开发永远都是在做重复型的工作。就我们自己实际情况来看，如果不是当初开发团队坚持使用直接代码的引用方式，并且要求程序员在开项目的同时不断对其进行扩充，我们也不可能有这样一个膨大的framework，但还说不上完善。不过，我们的framework想在已经拥有超过50个模块，内容涵盖系统配置，异常处理，数据库维护，报表维护，活动目录访问，安全等各个方面。非常引以骄傲。

呵呵，好像有点走题了，但是以上说的的确是使用直接代码引用的诸多好处。以上的开发方式我们大概使用了2年左右。最近我们已经将所有的引用都改成了dll的模式。我现在还记得当时把那一长串的framework引用删除的时候的快感。不过使用这种模式开始的时候也对不能直接修改framework中的代码觉得不方便，知道现在我们仍然在寻找一个可以好处兼顾的方案。

Project Reference Pros 直接源代码引用的好处：
1）便于程序员扩充framework
2）便于调试
3）减少开发团队人员开销，每个程序都有所有的代码，无需专门的人来维护
Cons 缺点：
1）不利于版本控制
2）项目结构复杂，难于管理
3）增加团队依赖性，如果多个团队同时使用一个framework，那么任何改动都会涉及所有的团队，往往会因为一个人的事务造成多个多个项目的停滞（我就因为一个变量的默认值设置错误造成2个项目的延误，当时是焦头烂额）。

我觉得对于小型软件公司来说，特别是还在知识积累阶段的公司，更适合使用直接源代码引用，因为这样可以加快公司的知识积累，并给所有的团队成员更多的接触公司核心代码机会，有利于培养团队。
对于相对大型的软件公司，如果有实力支持专门的framework开发，那么应该使用dll方式，并对内部进行相应的版本控制，这样可以更好的保证项目开发进度和质量。

以上只是我个人一点看法，希望跟大家讨论这个问题。