62,074
社区成员
发帖
与我相关
我的任务
分享自己设想的框架快要完成，散分！
框架两个特点：后台接口不用编程，随时添加。
前台去掉烦人的分页，加载几万条无压力！
只要在后台添加接口，再授权给用户，接口就可以访问了。
前台json {userName:'xxx',password:'xxxx',api:'CreateRole',RoleName:'xxx',Description:'ss'}就可以了。
原理很简单，后台根据json的用户和Api找到相应的sql语句，把参数替换，运行SQL，结果返回前台，简单粗暴。
前台用Extjs MVVM模式开发，加载几万条数据没啥问题，烦了点击取消就不再加载。
接口可以授权，前台权限也可以控制到按钮级，字段和显示都可控制。
如果用这个框架开发，速度是传统开发速度的3倍以上。
前台去掉烦人的分页，加载几万条无压力！
只要在后台添加接口，再授权给用户，接口就可以访问了。
前台json {userName:'xxx',password:'xxxx',api:'CreateRole',RoleName:'xxx',Description:'ss'}就可以了。
原理很简单，后台根据json的用户和Api找到相应的sql语句，把参数替换，运行SQL，结果返回前台，简单粗暴。
前台用Extjs MVVM模式开发，加载几万条数据没啥问题，烦了点击取消就不再加载。
接口可以授权，前台权限也可以控制到按钮级，字段和显示都可控制。
如果用这个框架开发，速度是传统开发速度的3倍以上。
...全文
请发表友善的回复…
发表回复
专注研发ERP低代码开发平台 2019-01-05
- 打赏
- 举报
不开源，开源就是费力不讨好的事情，自己几年做出来的东西给大家免费用，费心费力费神又没有人多给你一毛钱，还会有很多人来告诉你，你的东西就只是如此，没啥了不起的，你说闹不闹心？有开源的这份精力，还不如用来做些给自己创造价值的事情。
我有很认同这种开发方式的小圈子，这个小圈子我是共享代码的，有朋友一直想把这个平台商业化，但我觉的凭我个人的能力是没有办法做到商业化标准的，我也不可能放弃现在的工作，来把平台做成商业化，这样子做简单是找死。
我慢慢从纯技术岗位开始兼任管理，有时还会主导实施，对于平台工具也有不一样的认识。对于公司来讲，你的平台有没有新技术，有没有可以传播的东西不重要，至少在ERP行业是这样子的，极少ERP有非要用新技术才能实现的需求。ERP费心费力的无非就是增删改查，表单配置，流程控制，数据流转。这种需求完全可以使用平台工具来配置实现，没有什么高深的东西。我能使用我的平台将原来1年的开发时间缩短到4个月，将6个月的实施时间缩短至3~4个月，这个价值才是真正的真金白银。
我也很佩服那些专注于技术的技术大牛，论坛中不是有一位搞了十多年国产开发语言加全套软件开发工具的大牛么（https://bbs.csdn.net/topics/392378637），现在都不知道落魄成啥样了。没有大牛们的坚持，就没有软件业的进步，但我们普通人，还是以赚钱为主啦 
张天星 2019-01-05
- 打赏
- 举报
不开源，开源就是费力不讨好的事情，自己几年做出来的东西给大家免费用，费心费力费神又没有人多给你一毛钱，还会有很多人来告诉你，你的东西就只是如此，没啥了不起的，你说闹不闹心？有开源的这份精力，还不如用来做些给自己创造价值的事情。
我有很认同这种开发方式的小圈子，这个小圈子我是共享代码的，有朋友一直想把这个平台商业化，但我觉的凭我个人的能力是没有办法做到商业化标准的，我也不可能放弃现在的工作，来把平台做成商业化，这样子做简单是找死。
我慢慢从纯技术岗位开始兼任管理，有时还会主导实施，对于平台工具也有不一样的认识。对于公司来讲，你的平台有没有新技术，有没有可以传播的东西不重要，至少在ERP行业是这样子的，极少ERP有非要用新技术才能实现的需求。ERP费心费力的无非就是增删改查，表单配置，流程控制，数据流转。这种需求完全可以使用平台工具来配置实现，没有什么高深的东西。我能使用我的平台将原来1年的开发时间缩短到4个月，将6个月的实施时间缩短至3~4个月，这个价值才是真正的真金白银。
我也很佩服那些专注于技术的技术大牛，论坛中不是有一位搞了十多年国产开发语言加全套软件开发工具的大牛么（https://bbs.csdn.net/topics/392378637），现在都不知道落魄成啥样了。没有大牛们的坚持，就没有软件业的进步，但我们普通人，还是以赚钱为主啦
[/quote]那个帖子看了，不太相信。
毕竟，一个产品没有实践就能一直坚持下去，还是十几年，简直难以置信。
没有体验、实践的人，语言应该有什么内容你都不一定能够想清楚。难道直接照搬现有某个语言的整体结构么？
SinGooCMS 2019-01-04
- 打赏
- 举报
开源吗？开源就学习下！
SinGooCMS 2019-01-04
- 打赏
- 举报
自从要兼容SQLSERVER,MYSQL,ORACLE,SQLITE后，就尽量不直接写SQL语句了！
娃都会打酱油了 2019-01-04
- 打赏
- 举报
不管怎么样，只有能有自己的用途就行
以专业开发人员为伍 2019-01-04
- 打赏
- 举报
这个问题提的其实很巧妙。
这类代码一旦开源，可能就发现里边东西不多。因为前端用 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
- 打赏
- 举报
拼接SQL 安全性太差，容易被sql注入
netharry 2019-01-02
- 打赏
- 举报
没明白意思，能不能访问和接口有啥关系？接口分配个公网IP不就能谁都访问了吗？
你说的是不是这个意思。
不胖到130不改名字 2019-01-02
- 打赏
- 举报
楼主这些“接口”，别人能用代码联网访问吗？
如果不能，使用场景是否太狭隘了？
如果不能，使用场景是否太狭隘了？
极客诗人 2019-01-02
- 打赏
- 举报
把所有sql放在一个表配好参数 传个参数就把sql拼接好了
那么和那种模板 有什么区别呢。。。
正怒月神 版主 2019-01-02
- 打赏
- 举报
很同意 sp的观点。
现在流行的是富客户端。
注重前台的交互问题。
楼主列举的例子，感觉最多是一个可以连表查询展示gridview的模板页面。
但是缺少了用户交互的前端思想。
netharry 2019-01-02
- 打赏
- 举报
单表单很容易，这个框架不是基于单表单的，例如我的功能权限查询：
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
- 打赏
- 举报
单表单很容易，这个框架不是基于单表单的，例如我的功能权限查询：
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）
