换了一个新工作，来到新的公司当然最重要的就是要先熟悉公司的业务，我果断了通过tfs下载了公司的一个业务的源码，里面虽然有很多的封装功能我看不到具体实现，但是通过项目的结构我还是发现了一个公司项目能够成功的关键。
公司名我就不说了，说了大家会觉得我有点什么似的？咱就说我通过看公司源码发现了什么，我先说说这个源码项目是做什么的？这个源码是针对公安局进行调度的程序，就是相当于公安局接线员似的，听公司的老人说这个项目的功能，我以为没有什么复杂的，但是我拿到了公司的源码，我的妈呀，吓我一跳，一共有接近六十个项目，就是这一个解决方案中有六十个项目存在。这是我干软件那么长时间，第一次看到一个解决方案竟然需要那么多的项目存在，当然这并没有吓到我，我果断的拿出了纸和笔，把每个项目按照其分层结构以及功能分类，经过我那么一分类，发现其实就是不同分层结构。一共有那么几层存在：
- 客户端代理层 CliengAgent
- 客户端UI
- 客户端逻辑层 Client Logic
- 服务端服务层Service
- 服务端数据存取层 DAL
- 服务端ORM 层 ORM
- 数据传输层 DTO
- 接口层 Interface
当然这几层是我自己最后总结发现的，经过我这么一总结，我发现其实也就是传说中的分层结构，和我以前做的项目没有什么区别。让我的心里长抒了一口气，下面就是我针对每一层的所实现的功能进行剖析。我发现这一个项目的结构和我预想的还是有一定的差别，不知道是我的火候不够呢，还是公司的架构师水平不行呢？当然我认为肯定是第一种，因为我公司是国企，应该是架构师不止一个，虽然说我所在的开发二部没有架构师存在，但是架构师应该是千锤百炼的。
我看到首先就是代理层，我先把这个项目的调用关系介绍一下。
首先应用程序启动的是客户端代理层，这是我从来没有想到过的开发方式，通过代理层将UI层的界面以插件的形式进行加载，UI层相关的业务逻辑会调用客户端逻辑层，客户端逻辑层会通过.Net Remoting技术高效的调用服务层的方法，服务层通过DAL层进行增删改查操作，当然客户端与服务端的数据传输是通过DTO层进行的。
其中ORM层不是我原来认为的会通过ORM工具进行，而是数据实体层，可能是我没有看到里面具体的实现代码的原因，但是我看到的是ORM层是大量的数据实体，DTO层就是要传输的数据对象。她们会通过接口层进行方法的匹配调用。
通过这个项目，我不是说让我们了解到或者说学习到什么，我只是想说难怪每个程序员都不一样，设计出来的项目结构有时候也需要我们参考。原来多学习别人的设计可以带来这么多的用途。丰富自己的见解，能让自己耳目一新的感觉。
好了，不说废话了，我来说一下我通过这个结构学习到了什么？
首先就是客户端代理层，将UI以插件的方式进行加载，我个人认为这是个很不错的方法，代理层决定要加载哪些内容，而不是我们在界面上全部设计好，可以让代理层自己组装。
其次让我意外的就是数据传输层DTO的使用，说实话我一直就了解DTo的用途，但是我从来都没有想到过在实际的项目中要用到他。DTO和数据实体有一些区别。我在实际项目中一般都是传输数据实体，把数据库表对应的数据实体进行传输，当然我见到很多人都这样做，简单快捷，但是我今天看到了DTO层的单独使用，让我明白以后在追求好的解决方案的时候，开发上的快捷有时候会带来性能上的开销。我理解中的DTo应该是包括要传输的数据，但是可能包括一个表中的一个字段和另一个表的两个字段，这样通过DTo层可以很容易的实现，但是通过数据实体我们就需要传输两个对象，会无形中增加数据的开销。在一个追求效率和性能的项目中，应该是会绝对避免的吧。
第三个让我意外的就是那么多的项目结构，那么多类的开发，不同人的分工，竟然会咋那么短的时间内完成。我不得不佩服这些项目经理，如果在我以前的公司，这绝对是完成不了的，这就看出一个公司的管理是多么的重要，我离职的最重要的原因也是公司的管理不够，本来一个好的项目需要大家的共同努力，但是我们根本就不能提出意见，甚至我提出了一个建议，竟然被批评了那么长时间，甚至恶语相加。唉，不说也罢
总之，今天写这篇博客的目的就是让我们程序员的学习不要只是停留在书本上，要多看别人的项目代码，多研究别人的部分，任何一个程序员都会有他擅长的一面。所以我们不能只是看到自己多么的优秀，而忽略了他人的建议或优势。
今天的学习是为了明天的吃饱，不是仅有自己，还有孩子老婆。加油吧 朋友们
我又回来了，回到了技术最前线，
