程序员的自我救赎---1.1： 解决方案命分层规范
《Winner2.0框架解决方案命分层规范》
初学编程，难免要从Hello Word开始，学习Winner框架首先要知道如何建一个项目。有了第一个项目的框架结构就知道如何施展自己的"增删查改"。
Winner框架 依然遵从MVC模式，这里我就不去赘述什么是MVC。
数据层：以"项目名.DataAcces"命名，例如： Shop.DataAccess；
实体层：以"项目名.Entities" 命名 例如： Shop.Entities；
业务层：以“项目名.Facade”命名 例如：Shop.Facade；
显示层：以“项目名称” 命名 例如： Shop；
=======================华丽的分割线====================
winner 框架的核心库有 三个:
=======================华丽的分割线====================
数据库命名：
1.基础规范：
1.由于Oracle做大小写命名非常麻烦，所有统一采用PLSQL规范为大写。为了命名的可读性，每个单词与单词之间用下划线（“_”）隔开。
2.每个表、字段、试图都必须加上相关备注；
3.每个表的字段最后必须加上Remarks与Create_Time（默认为sysdate）字段；
4.凡是有字段在程序中为枚举的，则需要在备注中写明枚举名称和枚举值，例如用户状态的备注为：用户状态$UserStatus${未激活=0,已激活=1,已锁定=2}
2.命名规范：
1.表名： T模块_表名 例如：用户模块用户表，Tnet_Reginfo
2.试图： V模块_表名 例如：用户模块用户表，Vnet_Reginfo
3.主键： PK_表名 例如：PK_Tnet_Reginfo
4.外键： FK_表名_字段 例如：FK_Tnet_Reginfo_NodeId
5.唯一键： UK_表名_字段 例如：UK_Tnet_Reginfo_NodeCode
6.检查约束： CK_表名_字段 例如：CK_Tnet_Reginfo_NodeCode、
=======================华丽的分割线====================
代码生成器，会帮我们生成实体 和 数据库操作类，Winner框架将单条操作和 多条操作分成了两个类。
但是这两个类在同一个文件里，数据库操作类是以表为单位建文件。
XXX_XXXXCollection 类中所有的查询类要求统一以List开头例如： ListUserByStr()；ListUserByAccount()；关于继承的DataAccesBase 和 DataAccessCollectionBase 在后面的篇章中会详细讲到。
这里有一条要注意,winner框架是集成了，数据访问类。整个项目只需要通过配置即可访问数据库，不需要再画蛇添足的去写数据库访问类，我们团队曾经有个新入职的员工，不是特别懂框架开发了两天
进度一直没上来，结果他一个人自己闭门造车写数据库访问层，如果这些最基础的工作每个项目都要开发者来重复做一遍就不能称之为框架了。 我们很长一段时间开发中有新的公用类，或者比较常用的工具
我们都会集成到框架里来，整个框架除了 三个 核心dll，扩展的dll 以及第三方的dll加起来有一两百个，比如常见的：NPOI，Newtonsoft，SQLite。这些在TFS中的dll文件夹中都有的，而且一直在更新。
================================华丽的分割线==============================
Entities 实体层：
一般我们Winner框架的代码生成器会自动生成表所对应的实体以及字段在DataAccess中，但是我们实际开发中经常要跨应用对接
比如要跟Android对接、IOS对接，这个时候我们很多情况下要自己 写Model，并根据model 序列化Json。 所以Entities 主要职责是存放model，
除了，存放model实体以外Entities还有另外三项职责，总的来说如下四点：
1，存放实体Model
2，存放枚举对象
3，保存产量，或变量。
4，存放该项目需要的工具对象。
如下图：
上面还有很多，比如根据项目需求写RAS加密工具类，基本上能公用的阿杰都写在了Winner.Framework.Encrypt 和 Winner.Framework.Utils。
====================================华丽的分割线===============================
Facade 业务层：
这里，好多新人加入我们团队的时候就好奇这个事务居然不要在数据库中写，这个在后面的篇章中再详细讲，总而言之我们遵循一个原则：
数据库的职责是做存储数据，我们尽可能不去把业务逻辑放在数据库中去处理。
这里还出现了Alert()方法，这个也是从FacadeBase中继承而来，在调用业务Facade的时候，我们可能直接拿出Facade业务对象返还的Message错误信息。
在后期的项目篇章中这个Alert() 会出现很多。
另外，这里我们也有一个写Facade业务的基础思想“水渠思想”，就像河水变成自来水的过程，要经过多到工序，有一步有问题我们就结束。
所以，我们就一层层的判断。 但不是 用嵌套if去写， 而在if判断为false之后 直接return，为true 就执行下一步。
（好比：“河水过滤失败，不能进行下一步，返回。过滤成功，下一步开始杀毒，杀毒失败返回，杀毒成功，开始氯洗····一直到最后成功”）
中间每一笔以事务管理起来，失败就RollBack()，成功则Commit()。
====================华丽的分隔线=====================
项目 显示层：
最后的显示层，以前我们用的是Asp.Net，我们会有TopPageBase基类 和 CommPageBase，TopPageBase没有验证登录信息，
是给不需要登录的界面继承的，而继承了CommPageBase 的页面则必须要登录。 当然还有相应有很多前端插件，比如分页控件，日历控件等等。
但是现在.net主要都是使用 .net MVC了。 所以我们单独也有一个程序集 Winner.FrameWork.Mvc.dll。
如下图：
自此也Winner框架的解决方案也就描述的差不多，我们前端没有形成自己的一套JS库，更多的还是使用第三方库。常规的JQuery 和 KnockOut
我就不再做描述，这方面我个人也用的不好，在这方面Jason和阿jie 都非常厉害。
遗憾的是Winner框架 没有形成一套Winner前端的后台模板。相对Ace UI模板用的比较多，另外 Amaze UI 也有一些。
阿杰说他有写一套前端，目前在团队内部推广。如果没问题，我也希望Winner有自己的一套前端这样也能省很多事。
不过，我的终极想法是，代码生成器能直接生成前端，这样就更省事了。
好吧，关于解决方案的命名和结构就写到这里。
