自己设想的框架快要完成，散分！

2019-01-01 07:13:31 1.4k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

多传感融合内外参标定（二）：lidar-camera，PnP算法和自动化标定设想多传感融合内外参标定（二）：lidar-camera自动化流程设想lidar-camera的PnP算法问题简述3D-2D的PnP算法现有工具的差劲表现改进方案和自动化标定设想现有方案的方法不存在的精确强特征点自动化标定流程统计误差平均效应 lidar-camera的PnP算法问题简述多线激光雷达lidar和相机camera（我又想起了SLAM的派别之争），是无人驾驶里最重要的2种传感器。lid... 阅读详情

框架两个特点：后台接口不用编程，随时添加。
前台去掉烦人的分页，加载几万条无压力！

只要在后台添加接口，再授权给用户，接口就可以访问了。
前台json {userName:'xxx',password:'xxxx',api:'CreateRole',RoleName:'xxx',Description:'ss'}就可以了。
原理很简单，后台根据json的用户和Api找到相应的sql语句，把参数替换，运行SQL，结果返回前台，简单粗暴。

前台用Extjs MVVM模式开发，加载几万条数据没啥问题，烦了点击取消就不再加载。

接口可以授权，前台权限也可以控制到按钮级，字段和显示都可控制。

如果用这个框架开发，速度是传统开发速度的3倍以上。

...全文

PP究竟是如何算出来的? 剖析osu!的PP算法! 本文是笔者研究osu!戳泡泡模式PP算法的一个记录文章, 旨在帮助其他对PP算法感兴趣的玩家快速建立对PP算法的认知. 由于大部分内容是笔者的个人理解和经验谈, 可能存在错误或者偏差, 欢迎读者提出改进意见和补充内容.本文的代码片段来源于rosu-pp, rosu-pp是osu!lazer全模式算法的Rust实现, 也是目前最流行的PP计算库. 本文面向略有编程经验的读者, 读者不必深入了解Rust, 只需要具有本科级别的编程知识和数学知识即可理解本文内容. 阅读详情

netharry

.NET社区 62,271 成员 668,968 内容

+ 关注 + 加入社区

切换为时间正序

专注研发ERP低代码开发平台 2019-01-05

打赏
举报

引用 37 楼 SinGooCMS 的回复:

开源吗？开源就学习下！

不开源，开源就是费力不讨好的事情，自己几年做出来的东西给大家免费用，费心费力费神又没有人多给你一毛钱，还会有很多人来告诉你，你的东西就只是如此，没啥了不起的，你说闹不闹心？有开源的这份精力，还不如用来做些给自己创造价值的事情。我有很认同这种开发方式的小圈子，这个小圈子我是共享代码的，有朋友一直想把这个平台商业化，但我觉的凭我个人的能力是没有办法做到商业化标准的，我也不可能放弃现在的工作，来把平台做成商业化，这样子做简单是找死。我慢慢从纯技术岗位开始兼任管理，有时还会主导实施，对于平台工具也有不一样的认识。对于公司来讲，你的平台有没有新技术，有没有可以传播的东西不重要，至少在ERP行业是这样子的，极少ERP有非要用新技术才能实现的需求。ERP费心费力的无非就是增删改查，表单配置，流程控制，数据流转。这种需求完全可以使用平台工具来配置实现，没有什么高深的东西。我能使用我的平台将原来1年的开发时间缩短到4个月，将6个月的实施时间缩短至3~4个月，这个价值才是真正的真金白银。我也很佩服那些专注于技术的技术大牛，论坛中不是有一位搞了十多年国产开发语言加全套软件开发工具的大牛么（https://bbs.csdn.net/topics/392378637），现在都不知道落魄成啥样了。没有大牛们的坚持，就没有软件业的进步，但我们普通人，还是以赚钱为主啦

张天星 2019-01-05

打赏
举报

引用 40 楼专注开发ERP快速开发平台的回复:

[quote=引用 37 楼 SinGooCMS 的回复:]
开源吗？开源就学习下！

不开源，开源就是费力不讨好的事情，自己几年做出来的东西给大家免费用，费心费力费神又没有人多给你一毛钱，还会有很多人来告诉你，你的东西就只是如此，没啥了不起的，你说闹不闹心？有开源的这份精力，还不如用来做些给自己创造价值的事情。

我有很认同这种开发方式的小圈子，这个小圈子我是共享代码的，有朋友一直想把这个平台商业化，但我觉的凭我个人的能力是没有办法做到商业化标准的，我也不可能放弃现在的工作，来把平台做成商业化，这样子做简单是找死。

我慢慢从纯技术岗位开始兼任管理，有时还会主导实施，对于平台工具也有不一样的认识。对于公司来讲，你的平台有没有新技术，有没有可以传播的东西不重要，至少在ERP行业是这样子的，极少ERP有非要用新技术才能实现的需求。ERP费心费力的无非就是增删改查，表单配置，流程控制，数据流转。这种需求完全可以使用平台工具来配置实现，没有什么高深的东西。我能使用我的平台将原来1年的开发时间缩短到4个月，将6个月的实施时间缩短至3~4个月，这个价值才是真正的真金白银。

我也很佩服那些专注于技术的技术大牛，论坛中不是有一位搞了十多年国产开发语言加全套软件开发工具的大牛么（https://bbs.csdn.net/topics/392378637），现在都不知道落魄成啥样了。没有大牛们的坚持，就没有软件业的进步，但我们普通人，还是以赚钱为主啦

[/quote]
那个帖子看了，不太相信。
毕竟，一个产品没有实践就能一直坚持下去，还是十几年，简直难以置信。
没有体验、实践的人，语言应该有什么内容你都不一定能够想清楚。难道直接照搬现有某个语言的整体结构么？

SinGooCMS 2019-01-04

打赏
举报

引用 25 楼专注开发ERP快速开发平台的回复:

楼主看下我做的框架，这个框架我做了4年多了，现在还在持续开发，从用它开发第一个项目开始，到现在已经是第4个版本了，现在已经用它开发了十几个项目了，100万以上的项目有两个（能签这两个项目，我的框架功不可没）。 https://bbs.csdn.net/topics/392364712 这个是我之前在csdn发的贴。 http://www.lmwlove.com/ai/SubjectID25 这个是我更新的文档，不过好久没有更新了，没人关注。另外，大部分程序员是不能客观的评价这类快速开发平台的，因为程序员都有先入为主的习惯，瞧不上别人的做的东西，说不灵活啊，性能差啊，反正很多理由。还有些人以为自己随便搞搞，也能搞出同样的东西来。还有，你要说服其他的程序员使用你的框架是难上加难，除了上面说的原因外，就是这种平台大大简化了开发人员的工作量，让他们由"厉害"的开发工作变成了简单的系统配置工作，这是开发人员最不能接受的。楼主想要获得承认感，可以找做产品，做市场，做管理的那群人，他们会从不同角度发掘出你的框架的价值。

开源吗？开源就学习下！

SinGooCMS 2019-01-04

打赏
举报

自从要兼容SQLSERVER,MYSQL,ORACLE,SQLITE后，就尽量不直接写SQL语句了！

娃都会打酱油了 2019-01-04

打赏
举报

不管怎么样，只有能有自己的用途就行

以专业开发人员为伍 2019-01-04

打赏
举报

引用 37 楼 SinGooCMS 的回复:

开源吗？开源就学习下！

这个问题提的其实很巧妙。这类代码一旦开源，可能就发现里边东西不多。因为前端用 ExtJs 而并没有什么自己的设计，然后在服务器端生成一个 sql 语句绑定几个 CommandParameter 作为 DBCommand 参数，然后将查询结果（DataTable）输出。这基本上一个熟练的人随时可以 copy 一下几行 ADO.NET 查询数据库的代码并且改一下，编程也比较快（反正就是30秒钟跟3分钟的区别）。而框架通常是指比这个复杂得多的一些东西。所以好的框架是要问一下“开源吗？”这个问题。以现在的潮流，凡是不怕开源的，以开源形式提供的，大多都是有点东西可传播的。而生怕开源的，很多都是东西比较少的。所以说这类问题确实问到了各类框架宣传的软肋上。

抢眼~ 2019-01-03

打赏
举报

BLL层操做数据库，这没什么。关键是BLL端代码是复杂的，不能用一个sql语句来概括。假设真的能用一条sql语句来概括的话，那么其实满脑子也就是只有类似 sql server 管理控制台那种“增删改查”GRID界面。而“传统的开发速度"如果是指简单地拖拉1、2个Grid然后绑定sql语句进行增删改查，那么我觉得也就是实现现在真正的项目的开发费的千分之一功能。真正千分之999的功能是灵活的，是更加复杂的，是100%来自于用户专家的创意的交互界面。我们这里，但凡朋友打开一个软件，发现就是左边一个菜单、右边一堆简单的Grid列表附带简单的编辑，朋友们都说这些软件公司是骗子。现在的企业级编程，给用户实现100%集成在一起的、看上去复杂的灵活表单，一个表单往往涉及十几个数据库表，几百个字段。不是简单Grid。

weixin_43670769 2019-01-03

打赏
举报

额这个做了多长时间啊

leagiboy 2019-01-03

打赏
举报

设想不错需要实际项目检验

吉普赛的歌 2019-01-03

打赏
举报

这个做特定的东西，还是很好用的。我也做过类似的基于SQL直接导出报表。不过，有风险，小范围内用用还是不错的。

啊宝儿姐 2019-01-03

打赏
举报

可以，做点小东西很不错。比如商品列表，菜单列表啊啥的，非常方便。

大葡萄八块一斤 2019-01-02

打赏
举报

让我想到了java在配置文件里写语句配置参数

netharry 2019-01-02

打赏
举报

引用 16 楼刘才鬼的回复:

把所有sql放在一个表配好参数传个参数就把sql拼接好了那么和那种模板有什么区别呢。。。

拼接SQL 安全性太差，容易被sql注入

netharry 2019-01-02

打赏
举报

引用 17 楼 likelinsiyuan 的回复:

楼主这些“接口”，别人能用代码联网访问吗？如果不能，使用场景是否太狭隘了？

没明白意思，能不能访问和接口有啥关系？接口分配个公网IP不就能谁都访问了吗？你说的是不是这个意思。

不胖到130不改名字 2019-01-02

打赏
举报

楼主这些“接口”，别人能用代码联网访问吗？
如果不能，使用场景是否太狭隘了？

极客诗人 2019-01-02

打赏
举报

把所有sql放在一个表配好参数传个参数就把sql拼接好了

那么和那种模板有什么区别呢。。。

正怒月神版主 2019-01-02

打赏
举报

很同意 sp的观点。现在流行的是富客户端。注重前台的交互问题。楼主列举的例子，感觉最多是一个可以连表查询展示gridview的模板页面。但是缺少了用户交互的前端思想。

netharry 2019-01-02

打赏
举报

引用 13 楼圣殿骑士2018 的回复:

[quote=引用 6 楼 netharry 的回复:] [quote=引用 5 楼圣殿骑士2018 的回复:] 2楼说的非常到位。只能适用于增删改查的框架，只是玩具框架。这也是我一直批评的网上常见的基于Repository的框架的原因，它们实现了“完美”的单表操作，但99%的多表联合逻辑呢？无法实现。同时，这种框架，在非演示的实际场景中性能极差。为什么？因为将一个sql封装成一个接口，这是基于bs在做cs的事情。我在之前公司曾经因为远程vpn访问性能极低，将架构从cs改为bs。为什么？比如一个复杂的操作，要同时执行50个sql语句，如果是bs，这50个语句是在服务器一次性执行完，再反馈给网页端，而cs呢？千里之外的客户端需要和服务端进行50次以上的远程沟通，提交50个次接口，这个性能，只能在局域网用用。cs改bs后，虽然仍然是基于winform，但50次+的访问，改为数次webapi调用，远程访问的性能提升可几十倍。

单表单很容易，这个框架不是基于单表单的，例如我的功能权限查询： select top #{limit} C.* from(select ROW_NUMBER()over(order by FunctionName asc ) as rownumber,* from( select B.ID, A.ID as RoleID,A.RoleName,A.Description as RoleDesc,A.FunctionID,A.FunctionName,A.FunctionDesc,A.FunctionType,A.ViewID,C.ViewName,C.ViewPath,D.CategoryName, E.CodeName, Access= case when B.RoleID IS null then 0 else 1 end from (select * from _xRole A join _xFunction B on 1=1) as A left join _xRoleFunction B on A.ID=B.RoleID and a.FunctionID=B.FunctionID left join _xView C on A.ViewID=C.ID left join _xCategory D on A.CategoryID=D.ID left join _xDictionayData E on A.FunctionType=E.Code where (ISNULL(B.RoleID,'')='' or A.FunctionID=B.FunctionID) and E. DictionaryID=1 #{xClause}) as cc) as C where rownumber>(#{page}-1)*#{limit}; select COUNT(*) from (select * from _xRole A join _xFunction B on 1=1) as A left join _xRoleFunction B on A.ID=B.RoleID and a.FunctionID=B.FunctionID where (ISNULL(B.RoleID,'')='' or A.FunctionID=B.FunctionID) #{xClause} 这个复杂不？至于50条SQL语句，不明白和这个框架有啥关系？在这个框架了，你可以把SQL写的多复杂都无所谓，它只是替换参数和运行SQL而已。 [/quote] 我是不觉得这种开发效率能如何高效。我是不能忍受这种开发方式，这对我来说非常糟糕。 1、习惯了强类型的开发，用上了linq，我再也不想回去写sql的日子了。强类型才是高效的，易重构的。 2、一个复杂逻辑，有50个sql，在源代码中，是由很多分支语句，循环语句以及sql组合而成。我不知道，只用sql，如何能实现这么复杂的功能？如果能实现，那么用简单的sql语法来实现分支，循环，那简直是不可能，只能采用存储过程了吧。 3、你例子中的这个sql，看似简单，就一个sql。但， sql复杂了难以做性能优化；高效的开发IDE换成了一个简陋的文本框，只有sql没法写注释；别人要看懂你的这个逻辑，可能都得半天。你写的是爽，别人接手就是想死的心都有。现在，一个框架如果不考虑协作的效率，那不能叫高效框架。[/quote] 这个框架全是跨域的，缺什么都可以自己补，例如业务逻辑，你可以再编个接口。也非常感谢你花时间对这个框架说出自己的感受。

圣殿骑士18 2019-01-02

打赏
举报

引用 6 楼 netharry 的回复:

[quote=引用 5 楼圣殿骑士2018 的回复:]
2楼说的非常到位。只能适用于增删改查的框架，只是玩具框架。这也是我一直批评的网上常见的基于Repository的框架的原因，它们实现了“完美”的单表操作，但99%的多表联合逻辑呢？无法实现。

同时，这种框架，在非演示的实际场景中性能极差。为什么？因为将一个sql封装成一个接口，这是基于bs在做cs的事情。我在之前公司曾经因为远程vpn访问性能极低，将架构从cs改为bs。为什么？比如一个复杂的操作，要同时执行50个sql语句，如果是bs，这50个语句是在服务器一次性执行完，再反馈给网页端，而cs呢？千里之外的客户端需要和服务端进行50次以上的远程沟通，提交50个次接口，这个性能，只能在局域网用用。cs改bs后，虽然仍然是基于winform，但50次+的访问，改为数次webapi调用，远程访问的性能提升可几十倍。

单表单很容易，这个框架不是基于单表单的，例如我的功能权限查询：
select top #{limit} C.* from(select ROW_NUMBER()over(order by FunctionName asc ) as rownumber,* from(
select B.ID, A.ID as RoleID,A.RoleName,A.Description as RoleDesc,A.FunctionID,A.FunctionName,A.FunctionDesc,A.FunctionType,A.ViewID,C.ViewName,C.ViewPath,D.CategoryName, E.CodeName,
Access=
case when B.RoleID IS null then 0
else 1
end
from
(select * from _xRole A
join _xFunction B on 1=1) as A
left join _xRoleFunction B on A.ID=B.RoleID and a.FunctionID=B.FunctionID
left join _xView C on A.ViewID=C.ID
left join _xCategory D on A.CategoryID=D.ID
left join _xDictionayData E on A.FunctionType=E.Code
where (ISNULL(B.RoleID,'')='' or A.FunctionID=B.FunctionID) and E. DictionaryID=1 #{xClause}) as cc) as C where rownumber>(#{page}-1)*#{limit};
select COUNT(*)
from
(select * from _xRole A
join _xFunction B on 1=1) as A
left join _xRoleFunction B on A.ID=B.RoleID and a.FunctionID=B.FunctionID
where (ISNULL(B.RoleID,'')='' or A.FunctionID=B.FunctionID) #{xClause}
这个复杂不？至于50条SQL语句，不明白和这个框架有啥关系？在这个框架了，你可以把SQL写的多复杂都无所谓，它只是替换参数和运行SQL而已。
[/quote]
我是不觉得这种开发效率能如何高效。我是不能忍受这种开发方式，这对我来说非常糟糕。

1、习惯了强类型的开发，用上了linq，我再也不想回去写sql的日子了。强类型才是高效的，易重构的。
2、一个复杂逻辑，有50个sql，在源代码中，是由很多分支语句，循环语句以及sql组合而成。我不知道，只用sql，如何能实现这么复杂的功能？如果能实现，那么用简单的sql语法来实现分支，循环，那简直是不可能，只能采用存储过程了吧。
3、你例子中的这个sql，看似简单，就一个sql。但，
sql复杂了难以做性能优化；
高效的开发IDE换成了一个简陋的文本框，只有sql没法写注释；
别人要看懂你的这个逻辑，可能都得半天。你写的是爽，别人接手就是想死的心都有。

现在，一个框架如果不考虑协作的效率，那不能叫高效框架。

netharry 2019-01-02

打赏
举报

这个架构支持从不同服务器的数据库读取数据，例如user这个表在 192.168.1.3的服务器上的数据库里，另一张表叫 salary在192.168.1.4的服务器上，salary里有一个列是userID. 当用户查询salary这张表，总不能显示一个userID,要显示user表里的userName, Extjs就能从不同服务器的两张里读出数据，根据userID替换成userName,Extjs很容易实现。

加载更多回复（20）

自己设想的框架快要完成，散分！

相关推荐