开发现代化的.NetCore控制台程序:(1)项目介绍以及依赖注入/配置/日志等使用细节
开发.NET Core控制台工具,依赖注入和日志整合得比Go优雅多了。哼,配置文件丝滑,但AOT?反射问题,放弃。
STARBLOG / 技术与日常的文字存档
写下实践中的发现,也留住那些值得回看的想法。
开发.NET Core控制台工具,依赖注入和日志整合得比Go优雅多了。哼,配置文件丝滑,但AOT?反射问题,放弃。
又一个.NetCore模板?FluentConsole.Templates,一键生成骨架,包含DI、日志、配置。安装?dotnet new install,然后dotnet new flu-cli -n MyProject。太简单了吧,谁在乎?
作者弃bash、Python、C#,选Go写Hive导出工具,只因部署简单。Go的err处理烦人,但交叉编译省事。工具交互式,搞定导出。
EFCore居然没有内置命名转换?得自己写正则或用插件,真是折腾。插件一行代码搞定,但为什么EFCore不直接支持?命名风格转换,要么自己写代码,要么依赖第三方,真费劲。
很多项目一开始选型的时候没有选择EFCore,不过EFCore确实好用,也许由于种种原因后面还是需要用到,这时候引入EFCore也很方便。 本文以 StarBlog 为例,StarBlog 目前使用的 ORM 是 FreeSQL ,引入 EFCore 对我来说最大的好处是支持多个数据库,如果是 FreeSQL 的话,服务注册的时候是单例模式,只能连接一个数据库,如果需要使用 FreeSQL 同时
Docker部署RedisStack?呵,基础操作罢了。ACL权限?不过是Redis 6.0的标配功能。C#集成?官方NRedisStack包,一行代码的事。
C#开发者用iKVM白嫖JVM生态?省事,但依赖处理还得手动折腾。无缝接入?不过是把JAR转DLL,省了移植代码的麻烦。AI工具缺?直接调用HanLP,但依赖处理,呵呵。
下载音乐防灰,工具链折腾值不值?搭建私有流媒体,客户端体验一般般。数据自主权在手,平台下架算什么?
人脸检测与识别现在已经很成熟了,C# 上有 ViewFaceCore 这个很方便的库,但这种涉及到 native 调用的库,一般会有一些坑,本文记录一下开发和部署的过程。
之前我写过一篇使用 docker 部署 AspNetCore 应用的文章,这种方式搭配 CICD 非常方便, build 之后 push 到私有的 dockerhub ,在生产服务器上 pull 下来镜像就可以直接运行了。 然而,有时需要一种更传统的部署方式,比如在本地打包可执行文件之后直接放到服务器上执行。 这种方式配置完成之后,每次更新只需要重新本地重新 publish 后把可执行文件上传
我在使用 AspNetCore 的这段时间内,看了很多开源项目和博客,发现各种 .Net 体系的新技术很多人都有关注和使用,但却很少有人关注测试。 测试是软件生命周期中的一个非常重要的阶段,对于保证软件的可靠性具有极其重要的意义。在应用程序的开发过程中,为了确保它的功能与预期一致,必须对其进行测试。这样做不仅能够确保功能正确执行,同时能够帮助开发人员尽早地发现并改正系统中所存在的缺陷(Bug),
Vue 可以非常方便地与 Pure HTML 结合,代替 jQuery 的功能,有一次遇到类似的场景时,我就想 React 能不能也以这种方式接入 HTML 网页,从而提高开发效率。 结果当然是可以的,只不过在 HTML 里直接 JSX 似乎会降低一些性能… 凑合用吧
路由对象router给我们提供了beforeEach方法,可以在每次路由之前进行一些相关处理,也叫导航守卫,我们这里就通过导航守卫实现一些类似身份认证的辅助功能。 修改router/index.js文件,添加导航守卫,在每次路由时判断用户会话是否过期。如果登录有效且跳转的是登录界面,就直接路由到主页;如果是非登录页面且会话过期,就跳到登录页面要求登录。 代码如下 router.beforeEach
状态管理 在很多应用场景下,我们需要在组件之间共享状态,比如我们的左侧导航栏需要收缩和展开的功能,收缩状态时宽度很小,只显示菜单图标,因为导航菜单栏收缩之后宽度变了,所以右侧的主内容区域要占用导航栏收缩的空间,主内容区域宽度也要根据导航栏的收缩状态做变更,而导航栏和主内容区域是两个不同的组件,而非父子组件之间不支持状态传递,所以组件之间的状态共享问题发生了。 之前我写flutter的时候,响应式设
界面设计 按照ElementUI提供的布局来 左边是导航栏,右边上方是标签页,然后是主内容区 如图 二级类目 开始写代码 主页面的内容已经比较复杂了,全部写在一个文件内不现实 我们来分解一下 根据这个布局,页面可以分为头部、主体、左侧导航栏三部分 所以我来新建三个vue页面 HeaderBar.vue Navbar.vue MainContent.vue 完成之后目录结构如下 views ├──
前言 前端开发的准备工作在前面已经完成了,接下来就要开启写页面(Copy/Paste)操作了~ 用ElementUI写页面很简单,对照着官网文档代码一顿复制粘贴就完事了。 写代码 没啥好说的,直接代码 布局 template el-form :model=loginForm :rules=fieldRules ref=loginForm label-position=left label-wi
参考资料 前端通过axios和FormData实现文件上传功能遇到的坑:https://segmentfault.com/a/1190000016927601 Element el-upload上传组件详解:https://segmentfault.com/a/1190000013796215
用到的组件:vue-waterfall 项目地址:https://github.com/MopTym/vue-waterfall 参考资料 Vue<瀑布流加载效果>:https://www.jianshu.com/p/97b89597ab5c
markdown编辑器 v-md-editor,http://ckang1229.gitee.io/vue-markdown-editor/zh/ 在我的项目里最大化有问题,后面我自己搭配vuex实现了 优点是界面比较好,TOC可以放在左边 其他尝试 vue-element-admin整合的markdown编辑器:https://panjiachen.github.io/vue-element-a
其实几年前我就有轻度使用了一下 Blazor 这个技术,一开始使用 Blazor ,我是有点嫌弃的,我还是比较倾向于传统的前后端分离,AspNetCore用来做后端,用 React 做前端,生态很丰富,要做啥组件都容易。这次只是个小 Demo 项目,试用了一下 Blazor ,从一开始的非常别扭,到越来越顺手。感觉 Blazor Server 写小项目还是挺好用的,后面继续完善项目,持续发掘 B
本来今天开始是有其他的安排了,也没办法抽出那么多时间来学NetCore,不过我想做事情有始有终吧,除了gRPC还没跑起来之外,Blazor这部分也了解了一点。目前来说还不是很完善,真正的离线单页应用还处于预览版阶段。
最近遇到的这个场景,需要把之前开发的一套系统迁移到一个离线的服务器上,这个服务器有点麻烦,接入VPN后通过堡垒机才能访问,速度也很慢,遇到不少坑,本文记录一下迁移过程。
gRPC 使用起来非常的丝滑,目前来说也没遇到什么坑,可以非常平滑地与已有项目集成,如果有类似的场景,强烈推荐尝试一下 gRPC !gRPC 的功能很多,本文仅介绍了最基本的使用,更多的请阅读文档,详细有了本文的基础铺垫,读者再阅读文档深入使用时,会比较轻松上手。
RSS 的对立面是算法推荐,像微信公众号、知乎、微博、今日头条等平台。 且不说算法推送平台广告多,迁移麻烦的问题。算法推荐的特点是,你不需要刻意选择,算法会根据你的喜好,给你推送内容。这样一来,你几乎没有选择的余地,在不断被「喂饱」中逐渐失去判断的能力。