程序员的自我救赎---1.1： 解决方案命分层规范

《前言》

（一） Winner2.0 框架基础分析

（二）PLSQL报表系统

（三）SSO单点登陆

（四） 短信中心与消息中心

（五）钱包系统

（六）GPU支付中心

（七）权限系统

（八）监控系统

（九）会员中心

（十） APP版本控制系统

（十一）Winner前端框架与RPC接口规范讲解

（十二）上层应用案例

（十三）总结

 

 

《Winner2.0框架解决方案命分层规范》

 

初学编程，不免要从Hello Word开始，学习Winner框架首先要知道如何建一个项目。有了第一个项目的框架结构就知道如何施展本身的"增删查改"。

Winner框架 依然听从MVC模式，这里我就不去赘述什么是MVC。

 

数据层：以"项目名.DataAcces"命名，例如：  Shop.DataAccess；   

实体层：以"项目名.Entities" 命名    例如： Shop.Entities；

业务层：以“项目名.Facade”命名   例如：Shop.Facade；

显示层：以“项目名称” 命名  例如： Shop；

 

 

 

=======================华丽的分割线====================

winner 框架的核心库有 三个:

 

Winner.Framework.Core       （核心类dll）

Winner.Framework.Encrypt   （加密类dll）

Winner.Framework.Utils         （工具类dll）

 

整个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、

 

=======================华丽的分割线====================

 

 

 DataAccess 数据访问层：

 

只存放由代码生成器生成的数据访问类,以及咱们使用 “部分类” 本身根据需求扩展的数据库操做

这里咱们使用 “部分类” 部分类，也叫分部类，这里就不科普C# 语言基础知识了。（关于代码生成器，在下一篇中再详细概述）

 

以下图：

 

 

 

 

注意： 由代码生成器生成的 文件名规范为："表名.generate.cs" 本身扩展的不含“generate”字样以此区分。

 

 

 代码生成器，会帮咱们生成实体 和 数据库操做类，Winner框架将单条操做和 多条操做分红了两个类。

  可是这两个类在同一个文件里，数据库操做类是以表为单位建文件。

  

 

 

 这是代码生成器生成的带条操做，若是要根据需求扩展操做 着负责该类文件到Generate文件外,并删除文件名中的.generate。

 类文件中保留引用，命名空间，类名，删除里面的方法。

 

 

 

 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 业务层： 

  业务层用来，处理逻辑业务。一个业务一个类文件，业务类继承FacadeBase，而在Facadebase中集成了如：log4net，事务等功能。

在后面的篇章中会详细介绍Facadebase。

 

  命名规则为： “业务名Facade.cs”

 

以下图：

 

 

 咱们的业务层，基本只返回bool类型。听从面对对象的封装思想，就如同ATM机同样。只有一个插卡的“入口”，而后输入“参数“”密码

最后只有一个“出口”，出钱出来。  业务层里面的方法没有特别要求命名规范，听从驼峰命名法便可。

 

 

 

 

 

 

这里，好多新人加入咱们团队的时候就好奇这个事务竟然不要在数据库中写，这个在后面的篇章中再详细讲，总而言之咱们遵循一个原则：

数据库的职责是作存储数据，咱们尽量不去把业务逻辑放在数据库中去处理。

 

这里还出现了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有本身的一套前端这样也能省不少事。

不过，个人终极想法是，代码生成器能直接生成前端，这样就更省事了。

 

好吧，关于解决方案的命名和结构就写到这里。