SugarSite一个前端支持移动端的企业网站，目前只支持了简单功能，后续还会加上论坛等。
源码GIT地址：
https://github.com/sunkaixuan/SugarSite
技术介绍
Layui
个人而言不喜欢引用一堆东西，越简洁越好，layui正好能够满足我的这种需求，它是一款轻量级UI，JS部分都是采用模块化设计（AMD） ，对移动端支持比较不错。
唯 一不足是目前支持的组件有些少，需要有一定前端扩展能力的人才可以顺心使用。
用法：
例如我想用form.js和uploda.js我只需要写use(form,upload)（如下例代码所示），而不是引用两个JS文件
/*
Demo1.js
使用Layui的form和upload组件
*/
layui.use(['form', 'upload'], function(){ //如果只加载一个组件，可以不填数组。如：layui.use('form')
var form = layui.form() //获取form组件
,upload = layui.uplaod; //获取upload组件
//监听提交按钮
});
SqlSugar
一款高性能轻量级并且功能强大的ORM框架，支持多种数据库，支持.NET CORE 。MySql版支持了读写分离，SQL版支持了并行计算。
| Asp.net 4.+ | Asp.net Core | 说明 | 依赖 |
| SqlSugar.dll | SqlSugarCore.dll |
SqlServer ORM |
无 |
| MysqlSugar.dll | MysqlSugarCore.dll |
MySql ORM |
MySql.Data.dll |
| SqliteSugar.dll | SqliteSugarCore.dll |
Sqlite ORM |
System.Data.SQLite.dll SQLite.Interop.dll（Core版不需要） |
| OracleSugar.dll | - |
Oracle ORM |
Oracle.ManagedDataAccess.dll |
| SqlSugarRepository.dll | - | SqlServer MySql Sqlite Oracle 四合一 |
MySql.Data.dll System.Data.SQLite.dll Oracle.ManagedDataAccess.dll SQLite.Interop.dll
|
RestSharp
在我项目中作用与WCF相近，面向服务编程的一个核心要素，相比WCF更为简单更为轻量，只支持HTTP协议
var client = new RestClient("http://localhost/home/getjson");
// client.Authenticator = new HttpBasicAuthenticator(username, password);
var request = new RestRequest("resource/{id}", Method.POST);
request.AddParameter("name", "value"); // 添加请求参数
request.AddUrlSegment("id", "123"); // 添加 token
//添加HTTP头
request.AddHeader("header", "value");
// 添加文件
request.AddFile(path);
// 执行请求
IRestResponse response = client.Execute(request);
var content = response.Content; // 返回请求对象
// or automatically deserialize result
// return content type is sniffed but can be explicitly set via RestClient.AddHandler();
RestResponse<Person> response2 = client.Execute<Person>(request);
var name = response2.Data.Name;
//异步支持
client.ExecuteAsync(request, response => {
Console.WriteLine(response.Content);
});
var asyncHandle = client.ExecuteAsync<Person>(request, response => {
Console.WriteLine(response.Data.Name);
});
asyncHandle.Abort();
采用的设计思想
从古至今设计模式都是越复杂的大家越喜欢学，哪怕是学了完全都看不懂是个什么东西，就认为这技术高明，可能写的人自个都没明白，而相反代码写的越多的人越想写的简单。
模式这种东西就没有好坏之分：
不同人用不同的模式发挥出来的水平也不一样
我的领悟
嵌套逻辑不能超过3层，如果不符合这个约束在美的写法都要让步
1.冗余代码只要好维护也是可以接受的，复制粘贴一把凌，因为简单的逻辑而导致了代码的冗余，如果要做的不冗余那写法就要复杂的多，根据情况不同利弊自已选择，鱼和熊掌很多时候是不能兼得的。
2.一定要以业务为核心分层
3.易读的代码和改动少的写法有冲突的时候我会采用易读写法（别人都看不懂，还谈什么可维护性，自已做那是无所谓）
代码讲解
代码结构图：
我称这种模式为：指挥官模式
称词解释：
ViewAction ：类型为 ActionResult类型的Action
ApiAction： 类型为JsonResult类型的Action,在这里作为一个业务接口使用
Pack： 为一个业务块，并且业务块和业务块之间是隔离的，每个业务块有多个 ApiAction 和多个ViewAction，
业务块与业务块之间的通信用的是RestSharp调用其它Pack的
Outsourcing：业务块中的一些公用代码，可以是一个类也可以是一个文件夹，根据项目复杂度而定
这种架构模式和传统三层比起来有3大优势
1.分层容易并且代码更清晰
以前写法是以数据表作为服务，如果是SOA架构还要在抽象一层，当然一个复杂业务会有十张以上的表处理，便会出现这种垃机代码有几张表会出现几个Service
private x1 X1Service;
private x2 X2Service;
private X3 X3Service;
public DocContentController(x1 X1Service, x3 X1Service, x4X1Service) {
this.X1Service = X1Service;
this.X2Service = X2Service;
this.X3Service = X4Service;
}
现在写法,直接获取一个处理完的业务接口便可以，而不是获取每个细的表服务。
_service.Command<HomeOutsourcing, ResultModel<DocResult>>((o, api) =>
{
var DocLIST= api.Get(Url.Action("GetDoc"), new { typeId = typeId });
});
2.可以一套代码多平台使用
因为都是基于ApiAction如果权限合理完全可以当移动端接口，无形中已经是SOA架构。
3.层次简单
简单到比三层更精简
完成功能预览
前端
前端完美支持了所有主流移动端
后台
后台简单大方，没有为UI去设计，实用为主，发布IIS后能够验出不错的流畅感
目前只完成了基本的功能，后续会将这个开源项目一直写下去
喜欢就推荐一下
源码GIT地址：