【G】开源的分布式部署解决方案(二) - 好项目是从烂项目基础上重构出来的

G.系列导航

【G】开源的分布式部署解决方案 - 预告篇

【G】开源的分布式部署解决方案(一) - 开篇

【G】开源的分布式部署解决方案(二) - 好项目是从烂项目基础上重构出来的

分析目前项目结构

眼前出现这么一坨坨的文件夹,相信很多人已经看不下去了。是的,首先就是要把它给做掉。

按照这个项目文件夹的命名意图,大概可以划分如下:

1.Business:业务代码

2.Data:数据访问

3.Helpers:辅助类(通用类库之类的)

4.Models:各种模型(包括视图模型)

5.theme:皮肤,还有一些content、scripts之类的应该是要删除或整理到theme中。

6.Controller、Views、DB:这些就先不动他了。

按文件夹名的意图重新整理项目结构

首先整理出4个解决方案文件夹(注:解决方案文件夹是个虚拟的结构,并非真实的物理文件夹,虽然源码存放位置也缺失按照目前分层做的,但这个概念要分开),分别是 Business、Model、Data、Infrastructure,将业务、模型、数据、基础设施给分拆出来。

其中Business、Model两个文件夹主要与业务相关,这两个文件夹会根据功能模块创建对应的项目,比如 DeployManage、UserManage等。像部署下的一些小的概念,如部署服务器、部署服务器组、部署项目等这些只需要在对应项目下创建1级文件夹区分开即可。

而Data下拆分为2个,主要考虑到 Wrapper 是给Business用的,主要用来访问数据库,而Entities则是用于存放数据表对应的实体类。

最后的Infrastructure则把一些公共的类放到了这里。

可能有人不禁要问一下,就这么简单?这就是最终项目结构了吗?

当然不是,重构即是一个动作,也是一个过程。后面会根据项目发展不断的进行重构。

迁移过程中遇到的问题与解决

1.李鬼李逵傻傻分不清楚

首先遇到的问题则是它,AuthenticationDescription,按照已有的命名空间引用,正常推论是只要引用 Microsoft.Owin.Security.dll 就可以了。但事实证明不行。

为了知道到底是什么原因,我又把这个类放回原来的位置,F12跟踪进去一看,嘿,原来是个李鬼装李逵。

最终通过添加了Microsoft.Owin.dll 解决,这个类其实跟Microsoft.Owin.Security.dll没关系的。真真是被戏耍了一番。

2.雷锋,你做了好事倒是留个名啊

大家可能比较喜欢使用vs自带的这个小灯泡,是的它很方便,但它不是万能的。如果你按照这里的选项来做你有2个选择,要么新建一个类自己实现,要么引用 System.Runtime.Remoting.Context

虽然通过上面的办法我们也能找到最终是谁做的好事,但这个时候经验出现了,我一眼就看出来这是EF帮忙扩展了的(毕竟踩的坑多)。它做了好事儿,但它还没留下自己的名字,只告诉我它是个无名氏。当初第一次踩这个坑也是通过第一个方法解决的,性质跟是一样的,但这里想告诉大家,积累也很重要。

当处理到Business的时候,发现它终于可以给一个正确的提示了,这就好像A是B的老婆,B是C的同事,C认识B自然问B就知道A是谁了。

3.你女儿嫁人了她还是你女儿啊

把引用关系都改好了,过程中修改名字也都使用了大家喜欢的小灯泡同时更改所有的引用,为什么还会出现这个问题?难道View你就不管了吗?她不是你生的?

就是这个泼出去的水,你生的还要我来擦屁股。这里仅仅只是吐槽罢了。

看到了这个页面我长舒了一口气,终于是不报错了。

再来看下 G.Client.UI.Admin 好像是顺眼多了。

但这就改完了吗?这只是个开始而已,后面的路还长呢。

4.青春痘长在别人脸上你最不担心?

好好的一个业务层代码,引用了EF,着实是不爽。不仅如此,Model里也引用了System.Web来获取UserID。

作为一个有道德的人,别人脸上长了青春痘,你应该拿个扬声器对着他喊:喂,你脸上有青春痘,好大一颗,好难看!

nonono,作为一个有文化的人,我当然会解决你的痛处。而不是现在,后面一定会做的。其实很简单,只需要在Wrapper里封装好EF的操作,让Business不会直接引用到EF相关的功能即可。(这个是.net的机制不深究了)

同样的,System.Web的也通过Infrastructure里提供就好了。从此再也不担心青春痘乱长了。

代码方面的调整

作为一个懒人,第一个要解决的肯定是解放双手。

后面对数据库操作的还有好多地方,到处都要这样赋值真的是心疼自己细白嫩长的五指。

已经有很多人想到了AutoMapper吧?当然也有人喜欢EmitMapper等等。各有所长,萝卜白菜自己挑一个啃了吧。用法我就不多说了,看个最终代码。当然我用的是自己又封装一次的AutoMapper。

即便AutoMapper已经很灵活了,但每个人的习惯不同,总有你觉得不爽的地方,那就自己动手吧。

啧啧啧,瞬间又顺眼了好多,整个人都好了。

PS:这次引用的Mapper是我们自己写的,Framework.Mapping和Framework.Caching。暂时还没有开源,后面会放出来,其实也没加壳混淆,你有兴趣肯定难不住你的。

下一篇预告:【G】开源的分布式部署解决方案(三) -  部署项目管理(以Jenkins为例,准备好部署文件包)

最后最后,本项目暂定名为 G,唯一群号:7424099

Git地址:http://git.oschina.net/doddgu/G   (希望大家可以顺手点个star,感谢各位的支持)

时间: 2024-10-14 10:05:12

【G】开源的分布式部署解决方案(二) - 好项目是从烂项目基础上重构出来的的相关文章

【G】开源的分布式部署解决方案(三) - 一期规划定稿与初步剖析

G.系列导航 [G]开源的分布式部署解决方案 - 预告篇 [G]开源的分布式部署解决方案(一) - 开篇 [G]开源的分布式部署解决方案(二) - 好项目是从烂项目基础上重构出来的 [G]开源的分布式部署解决方案(三) - 一期规划定稿与初步剖析 抱歉 首先我先说声抱歉,因为上一篇结尾预告第三篇本该是“部署项目管理”,那为什么变成本篇呢? 请容我解释一下,在预告篇到现在为止,经常会有人问我这个项目到底是干什么的.或许之前写的比较粗糙.那我相信目前定稿后的功能概览图应该会给大家一个比较清晰的认识.

【G】开源的分布式部署解决方案文档 - Web Deploy

G.系列导航 [G]开源的分布式部署解决方案 - 导航 微软官方部署方式 右键项目->发布 这个大家应该再熟悉不过,在部署前有个预览界面可以看本次更新到底更新哪些文件. 既然它可以预览部署结果,那其实它部署也不会完全覆盖,而是采取部分覆盖的方式,并提供了增.删.改的实际数量. 这都要依赖一个叫做 Web Deploy 的项目. 传送门 当然,web deploy功能绝不仅仅如此,包括打包.备份.还原.更新数据库等. 在此不多做普及,提到了它的优点,自然要支持它.所以本项目支持原始+Web Dep

【G】开源的分布式部署解决方案文档 - 手动安装

G.系列导航 [G]开源的分布式部署解决方案 - 导航 序言 因各种原因,决定先写使用文档.也证明下项目没有太监.至于安装过程复杂,是因为还没有做一键安装,这个现阶段确实没精力. 项目进度 (点击图片看大图) 必备工具 IDE:VS2015+ 运行环境: .Net Framework 4.6.1(已测可降4.5,其余没测) 宿主:IIS 下载源码 源码地址 http://git.oschina.net/doddgu/G/ ps:强烈希望顺手点下 star.watch.fork VS克隆源码 编译

ios7.1安装提示"无法安装应用程序 因为证书无效"的解决方案二(dropbox被封项目转移到Appharbor上)

6月18日起dropbox被天朝封了(这个真是无力吐槽),而ios7.1要求使用ssl安全连接,则需要重新找到一个支持https的免费服务器.Appharbor是个不错的选择,操作简单,此外需要添加配置文件来识别plist,ipa文件,有关如何使用Appharbor转自: 免费ASP和ASP.NET空间Webweb和.NET云计算空间Appharbor 一.Appharbor免费.NET云计算空间申请 PS:Appharbor官网: https://appharbor.com/ 1.进入Apph

hyperledger fabric 1.0.5 分布式部署 (二)

环境:2台 ubuntu 16.04 角色列表 角色 IP地址 宿主端口 docker端口  peer0.org1.example.com  47.93.249.250  7051  7051  peer1.org1.example.com  47.93.249.250  7051  8051  peer0.org2.example.com  47.93.249.250  7051  9051  peer1.org2.example.com  47.93.249.250  7051  10051

lduan SCO 2012 分布式部署(二)

阿里开源分布式事务解决方案 Fescar 全解析

广为人知的阿里分布式事务解决方案:GTS(Global Transaction Service),已正式推出开源版本,取名为"Fescar",希望帮助业界解决微服务架构下的分布式事务问题,今天我们一起来深入了解. FESCAR on GitHub https://github.com/alibaba/fescar 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,系统微服务化后,一个看似简单的功能,

项目分布式部署那些事(1):ONS消息队列、基于Redis的Session共享,开源共享

因业务发展需要现在的系统不足以支撑现在的用户量,于是我们在一周之前着手项目的性能优化与分布式部署的相关动作. 概况 现在的系统是基于RabbitHub(一套开源的开发时框架)和Rabbit.WeiXin(开源的微信开发SDK)开发的一款微信应用类系统,主要业务是围绕当下流行的微信元素,如:微官网.微商城.微分销.营销活动.会员卡等. 关于RabbitHub详情请戳: .NET 平台下的插件化开发内核(Rabbit Kernel) RabbitHub开源情况及计划 关于Rabbit.WeiXin详

阿里微服务架构下分布式事务解决方案-GTS

虽然微服务现在如火如荼,但对其实践其实仍处于初级阶段.即使互联网巨头的实践也大多是试验层面,鲜有核心业务系统微服务化的案例.GTS是目前业界第一款,也是唯一的一款通用的解决微服务分布式事务问题的中间件,而且可以保证数据的强一致性.本文将对GTS做出深入解读. 微服务倡导将复杂的单体应用拆分为若干个功能简单的.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.概念2012年提出迅速火遍全球,被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.根据Netfl