AspNetCore开发笔记:WebApi项目集成企业微信和公众号
微信开发文档烂得离谱,直接用SKIT库搞定。异步处理消息,图片下载内存处理,公众号被动回复5秒内搞定。啧啧。
STARBLOG / 技术与日常的文字存档
写下实践中的发现,也留住那些值得回看的想法。
微信开发文档烂得离谱,直接用SKIT库搞定。异步处理消息,图片下载内存处理,公众号被动回复5秒内搞定。啧啧。
Blazor全栈?别逗了,这玩意儿就是陷阱。生态弱得可怜,AI都不给力,文档还老变。真以为能脱离前端?醒醒吧,小demo可以,真业务?省省吧。
试用了一下,感觉还是太折腾,用回原来的 AspNetCoreRateLimit 组件得了
既要在项目发布后访问 SwaggerUI ,又要保证一定的安全性,本文提供的思路或许是一种比较简单又有效的解决方案。
用ActionFilterAttribute搞非侵入校验,省得重复写代码。支持Query、Body、Route、Header,HttpContext共享数据,但OAuth2.0边学边做,项目乱糟糟,功能凑合。
现在已经可以实现对业务代码完全无侵入的审计日志了,在需要审计的接口上加上 `[AuditLog]` 特性,就可以记录这个接口的操作日志,还有相关的实体变化记录,还算是方便。
用alpine镜像?不过是把体积砍半,健康检查加个路径就完事。wget自带,何必装curl,真是多余。发布选linux-musl-x64,不然别想跑。
审计日志不仅仅是一种遵循最佳实践的手段,更是确保数据安全、提高系统透明度、促进责任归属明晰的关键工具。
EFCore居然没有内置命名转换?得自己写正则或用插件,真是折腾。插件一行代码搞定,但为什么EFCore不直接支持?命名风格转换,要么自己写代码,要么依赖第三方,真费劲。
很多项目一开始选型的时候没有选择EFCore,不过EFCore确实好用,也许由于种种原因后面还是需要用到,这时候引入EFCore也很方便。 本文以 StarBlog 为例,StarBlog 目前使用的 ORM 是 FreeSQL ,引入 EFCore 对我来说最大的好处是支持多个数据库,如果是 FreeSQL 的话,服务注册的时候是单例模式,只能连接一个数据库,如果需要使用 FreeSQL 同时
之前我写过一篇使用 docker 部署 AspNetCore 应用的文章,这种方式搭配 CICD 非常方便, build 之后 push 到私有的 dockerhub ,在生产服务器上 pull 下来镜像就可以直接运行了。 然而,有时需要一种更传统的部署方式,比如在本地打包可执行文件之后直接放到服务器上执行。 这种方式配置完成之后,每次更新只需要重新本地重新 publish 后把可执行文件上传
我在使用 AspNetCore 的这段时间内,看了很多开源项目和博客,发现各种 .Net 体系的新技术很多人都有关注和使用,但却很少有人关注测试。 测试是软件生命周期中的一个非常重要的阶段,对于保证软件的可靠性具有极其重要的意义。在应用程序的开发过程中,为了确保它的功能与预期一致,必须对其进行测试。这样做不仅能够确保功能正确执行,同时能够帮助开发人员尽早地发现并改正系统中所存在的缺陷(Bug),