SugarSite一个前端支持移动端的企业网站,目前只支持了简单功能,后续还会加上论坛等。前端
源码GIT地址:git
https://github.com/sunkaixuan/SugarSitegithub
我的而言不喜欢引用一堆东西,越简洁越好,layui正好可以知足个人这种需求,它是一款轻量级UI,JS部分都是采用模块化设计(AMD) ,对移动端支持比较不错。sql
惟 一不足是目前支持的组件有些少,须要有必定前端扩展能力的人才能够顺心使用。数据库
用法:编程
例如我想用form.js和uploda.js我只须要写use(form,upload)(以下例代码所示),而不是引用两个JS文件json
/* Demo1.js 使用Layui的form和upload组件 */ layui.use(['form', 'upload'], function(){ //若是只加载一个组件,能够不填数组。如:layui.use('form') var form = layui.form() //获取form组件 ,upload = layui.uplaod; //获取upload组件 //监听提交按钮 });
一款高性能轻量级而且功能强大的ORM框架,支持多种数据库,支持.NET CORE 。MySql版支持了读写分离,SQL版支持了并行计算。设计模式
Asp.net 4.+ | Asp.net Core | 说明 | 依赖 |
SqlSugar.dll | SqlSugarCore.dll | SqlServer ORM api |
无 |
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
|
在我项目中做用与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:业务块中的一些公用代码,能够是一个类也能够是一个文件夹,根据项目复杂度而定
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地址: