该Solution的所有Project如下：
下面对各个Project一一进行介绍：
Eallies.OA.BLL：用于系统中BLL层的所有类的存放。该Project可以采用Eallies.Utilities.ContractToBLL工具自动完成，对应于Eallies.OA.Generator目录下的GenerateBLL.bat文件。
Eallies.OA.Service：用于系统中后台服务层的所有类的存放。该Project可以采用Eallies.Utilities.BLLToService工具自动完成，对应于Eallies.OA.Generator目录下的GenerateService.bat文件。
Eallies.OA.Service.Contract：用于系统中后台服务层的Contract的所有接口的存放。该Project比较重要，包含重要的业务逻辑，它的完成，需要对系统的业务逻辑有很深的了解，因此该Project应该由业务逻辑开发人员来完成。
Eallies.OA.Service.Contract.Fault：用于系统中WCF技术错误处理的类的存放。
Eallies.OA.Service.Host：用于系统中后台服务层的Host的所有文件的存放。该Project可以采用Eallies.Utilities.ServiceToHost工具自动完成，对应于Eallies.OA.Generator目录下的GenerateHost.bat文件。
Eallies.OA.Service.Wrapper：用于系统中后台服务层的Wrapper的所有类的存放。一般来说，应该遵循谁提供Web Service，谁就完成Service Wrapper的原则来开发，这是因为，Web Service的任何修改，只有开发Web Service的人知道。该Project可以采用工具自动完成，对应于Eallies.OA.Generator目录下的GenerateWrapper.bat文件。
其它Project均在数据库开发人员的Solution中介绍过。
为什么UI层不直接调用BLL层，而是要经过UI->Service.Wrapper->Service.Host->Service->BLL这样绕一大圈的方式来调用BLL层呢？这是因为：第一，直接调用会导致系统耦合度太高，任何后台的改动都会导致前台需要重新编译、发布，而这样做了之后，只要Contract不改变，则前台不用做任何改动；第二，这样做了之后，比较适合SOA的理念，系统的扩展性、交互性和灵活性大大提高；第三，直接调用会导致Solution中会有过多的Project，编译非常慢，导致开发人员的时间浪费过多。
本文转自 Eallies 51CTO博客，原文链接：/eallies/79039，如需转载请自行联系原作者
