关于存储层以及读取函数的抽象

[kaybinwong]

第三方存储无论从性能上以及使用上都优于文件存储，有必要对存储层进行抽象。

[kaybinwong]

另外，对于框架本身建议做成core+plugin的形式，这样对于框架本身就是无入侵的，使用上会灵活很多。

[foolcage]

1)sqlalchemy提供了比较好的抽象，支持其他sql类型存储比较容易，多存储支持，改动不大。 项目主要定位还是单机pandas内存计算，存储只是辅助。

2)目前其实是core+plugin的形式，只是一开始a股的实现放一起了。其他标的会以plugin提供。

[kaybinwong]

1)sqlalchemy提供了比较好的抽象，支持其他sql类型存储比较容易，多存储支持，改动不大。 项目主要定位还是单机pandas内存计算，存储只是辅助。

2)目前其实是core+plugin的形式，只是一开始a股的实现放一起了。其他标的会以plugin提供。

项目这样定位的话这样设计已经很棒了，对大部分想搞量化但又无从下手的人提供了一个良好的环境。 但是对于很多“上道”的人，这是一个控制权的问题，不见的大家都用sqlalchemy，若是用它就得跟模型强耦合，实际上反而显得不灵活。

[foolcage]

@kaybinwong 抽象的数据层需要平衡，毕竟查询能力还是依赖“实现”，项目目前是强依赖sql类型的数据库，并且使用上不使用"约束"，方便各种sql库的兼容。

项目里面存储只是辅助“持久化”的方式，重要的还是数据的组织和计算，本意是想尽量不使用复杂的it技术，尽快的用pandas撸出自己模型。

抽象的数据层，存储类型映射和查询能力定义是很难的，如果有，也是一个中间件该干的事，好像没看到？

[doncat99]

完全的解耦好像也不是什么太好的事，抽象的数据层我看到有项目通过yaml定义，但是读起来比较晦涩难懂。对自身项目数据玩得溜的，确实乐在其中，但是倒是对刚接触者太不友好。这个项目如果能融合切入到目前流行的fastapi框架内就好了。 https://github.com/leosussan/fastapi-gino-arq-uvicorn

[foolcage]

完全的解耦好像也不是什么太好的事，抽象的数据层我看到有项目通过yaml定义，但是读起来比较晦涩难懂。对自身项目数据玩得溜的，确实乐在其中，但是倒是对刚接触者太不友好。这个项目如果能融合切入到目前流行的fastapi框架内就好了。 https://github.com/leosussan/fastapi-gino-arq-uvicorn

template只是方便按contract写其他标的或provider的插件，不使用也是可以的。