看到这样一个问题，低头看看你的solution里面，有多少个projects？
如果我在2个月之前拿这样一个问题去问我的程序员们，他们会告诉我，大概25个，45个，50个，还有可能更多；同时他们还会抱怨说：我的电脑太慢了！！我要同时编译太多的projects。1G内存是我这里每个程序员的标准装备，但是几乎每个人都在使用1.2G的内存，结果就是大量的内存交换，性能急剧下降。
然后大家开始需要更多的内存，更好的电脑。但是问题是我们真的需要这么大的内存来编译我们的程序吗？造成这种情况的原因在于我们的开发方式，我们公司有一个膨大的Framework，几乎所有的项目都要引用5个以上的Framework，这就意味这你的项目还没有开始，你就已经有5个projects需要编译，如果再把自动生成的程序代码，3层结构考虑进去，那么十几个projects将十标准的情况。其实我一直都不太同意直接引用framework的做法，网上也有很多关于这个问题的讨论。当初使用这样的机构主要的考虑是为了程序员更加便捷的对framework进行扩充，其实每个开发人员都一样，如果能很快的解决问题，那么大家都不愿花费时间来编写可从用的代码。而且大家对framework的看法一般都是别人开发好我来用，并希望有人专门来负责这一块。但是对于中小型的软件公司来说，我们没有多资金来专门雇人维护自己的framework，但是如果没有这样的东西，那么我们的开发永远都是在做重复型的工作。就我们自己的情况来看，如果不是当初开发团队坚持使用直接的引用方式，并且要求程序员在开发客户项目的同时不断扩充，我们也不可能有这样一个膨大的framework。我们的framework想在已经拥有超过50个模块，内容涵盖系统配置，异常处理，数据库维护，报表维护，活动目录访问，安全等各个方面。这样一个framework我们非常引以骄傲。
呵呵，好像有点走题了，但是以上说的的确是使用直接引用的诸多好处。现在“话锋一转”，以上的开发方式我们大概使用了2年左右。最近我们已经将所有的引用都改成了dll的模式。我现在还记得当时把那一长串的framework引用删除的时候的快感，和visual studio在5秒内编译完成的时候我的惊讶，一个字“爽”。不过使用这种模式开始的时候也对不能直接修改framework中的代码觉得不方便，知道现在我们仍然在寻找一个可以好处兼顾的方案。
Project Reference Pros 直接项目因引用的好处：
1）便于程序员扩充framework
2）便于调试
3）减少开发团队的相互依赖性，因为每个程序都有所有的代码
Cons 缺点：
1）不利于版本控制
2）项目结构复杂，难于管理
3）增加团队依赖性，如果多个团队同时使用一个framework，那么任何改动都会涉及所有的团队，往往会因为一个人的事务造成多个多个项目的停滞（我就因为一个变量的默认值设置错误造成2个项目的延误，当时是焦头烂额）。
我觉得对于小型软件公司来说，特别是还在知识积累阶段的公司，更适合使用project reference，因为这样可以加快公司的知识积累，并给所有的团队成员更多的接触公司核心代码机会，有利于培养团队。
对于相对大型的软件公司，如果有实力支持专门的framework开发，那么应该使用dll方式，并对内部进行相应的版本控制，这样可以更好的保证项目开发进度和质量。
以上只是我个人一点看法，希望跟大家讨论这个问题。
|