用.nettiers生成代码的时候有一个选项 IncludeComponentLayer，有None，ServicesLayer和DomainModel三个选项，看示例好像都是比较喜欢用ServicesLayer,不过我比较喜欢选DomainModel，这两个选项按我粗浅的理解就是一个用的是失血模型，一个是充血模型，ServicesLayer里面生成了很多的具体操作，但是不包括数据，示例是这样子的：
AccountService accountsService = new AccountsService(); //GetAll() TList<Accounts> accountList = accountsService.GetAll();
这里Accounts是 Entities里面的东西，而按DominModel的做个类似的操作是这样的：
TList<Accounts> accountList=Accounts.GetAll();
Services 里的 Accounts继承于Entities的Accounts，而且加上了各种的具体方法，
从代码上来看毫无疑问是下面的这个方法用起来更自然，用上面的方法，每次要取得一个实体，还要去调用一下该实体的Service类的方法，等于多了一步操作。
其实之前看了下BlogEngine里面的代码，好像也是用这种充血的模型，就是把数据和操作放在一个类里面，而PetShop则是用的失血模型，表里面的每个列都有一个加上info代表数据的类，看了下两种模型的区别是这样子的，失血模型分层比较清晰，数据的归数据，操作的归操作，缺点是BLL层的职责过重，所有的操作都在BLL层了，而充血模型则比较符合面向对象，缺点是职责划分不明确，比如有一个order类，到底应该什么操作放在order类里面，什么操作放在其他地方分的不清楚，如果一个人写代码还好，在团队合作的时候每个人写的不一样就会导致很多的混乱。
使用Domain Model时，我们需要在应用程式中加入一个完整的对象层，这些对象模仿业务系统中的对象及其逻辑规则，这和Transaction Script中对象仅仅是数据不包含业务逻辑形成最大的差别
一个Simple Domain Model看上去和数据库设计非常相似，每个Domain Object对应一个数据表，能使用Active Record模式来和数据库交互；Rich Domain Model则不然，通过使用继承，策略等模式和相互关联的对象网，Rich Domain Model能更好的处理更复杂的逻辑，同时也增加了和数据库间映射的难度，这时能采用Data Mapper模式来应对。
基于业务逻辑的多变性，数据对象层也应该能够更灵活的建立，修改和测试，这样，我们必须尽量减少该层同其他层次间的耦合。
When to use it
当你面对一个涉及验证，计算等等复杂多变行为的业务规则时，你需要考虑使用Domain Model。使用Domain Model时，数据库交互方面的第一选择是Data Mapper，他有助于使你的对象层同数据库独立。你也能考虑使用Service Layer来给你的Domain Model暴露出更加清晰的API。
使用Domain Model非常大的好处是，通过对象类的继承多态等性质，能方便的扩展模型，以适应多变的企业逻辑，同时减轻重复代码的现象。
和Transaction Script的差别
Transaction Script ： 从数据库读取数据 -〉 以读取的数据集作为参数，调用Transaction处理类
Domain Model ： 从数据库读取数据 -〉 映射为数据对象类 -〉 调用对象类的成员函数来处理企业事务