argon的模块化方案（新）

很longlong ago讨论数据库的时候，其实主要就是讨论我们的模块化 方案，但由于过度讨论了ORM，导致重点没有突出来…… 现在重新 谈一下。

出炉一会的argo的功能与特性一览： http://bbs.sysu.edu.cn/bbstcon?board=Suggest&file=M.1340954702.A

模块化有多么重要

模块化太重要了。这里只说一下为什么argon的模块化非常重要。

首先是我们开始的时候就是需要支持多终端的。基本的要求就是telnet和web 都要支持。回顾我们讨论过的分层

| telnet | web | 手机 ... | | model数据表达 | | mysql | redis | ... |

实际上，我们在telnet和web做的事情很大一部分都是逻辑上相同或者相似的。 我们希望把这部分逻辑实现放在model层，然后telnet和web都可以使用这些 代码。

这个也是为什么需要先实现telnet的原因之一。首先telnet是我们开发的最不稳定 的地方之一（没有使用成型的库，人手不够测试不足），尽早完成然后充分测试， 保证当前用户不受干扰。其次，telnet的功能最多最复杂，而其表现（在telnet的 部分）在chaofeng完成后其实已经问题不大。实现telnet意味着model的核心部分 已经完成了，这时候web就可以比较专注而高效地完成web端的表现。其它端 也是如此。

比如现在我们有一个 manager.post.get_posts(self, boardname, num, limit)是 可以直接在telnet和web使用的。

其次，是新系统需要保持扩展性，尽量避免硬编码，保持简洁以使后来的维护者 可以维护。新系统可以实现的非常复杂，但是要避免如此。新系统的功能不可能 一触而就，只能是抱着很多bug上线，然后不断修复bug和实现其它的模块。 简单可行的模块化方案保证我们可以很轻松地做这些

实现模块化

参考了一下一些phpbb的文档（没有看源码），有理由相信他的模块化是很好的， 可惜没有专门的文档来说明。

目前我们的实现：

1 使用一个继承于model的新类来表示逻辑上相连的一个模块。 2 一个新类基本上对应于一个sql表或者一些redis相同前缀的键，对应 他们相关的操作。 3 用功能来划分模块。 4 使用额外的manager类来结合这些model新类，表达层通过manager来 调用相关接口。 5 使用胶水model来完成多个model协同完成的功能。

比如，一个section类是用来处理分类讨论区（对应与section表）：

Class Section(Model):

def get_all_section(self) def get_section(self, name) def add_section(self, **kwargs) def update_section(self, sid, **attr) def del_section(self, sid) def name2id(self, sectioname)

有意思的设置一个板块属于哪个讨论区，并不是section负责的， 而是board负责的。这个主要是基于2的原则，因为在数据库的设 计中，board属于的section其实board表里面的一个属性。保持 这种直接和粗暴。

再比如，牛B闪闪的已读未读标记。很有趣的一个功能是，如果 一篇帖子没有读过，是会显示为N的。这个的实现是ReadMark类：

class ReadMark(Model): def is_read(self,userid,boardname,pid): def set_read(self,userid,boardname,pid): def clear_unread(self,userid,boardname,last):

telnet和web层直接调用 manger.readmark.is_read就可以判断了。

目前的模块化可能不是特别好，不过的确已经是可以满足需求了：

需要接口？ = 属于某个model？ =Y 添加到这个model =N 实现一个新的model

然后我们把整个系统，分成一个一个的model，然后实现一个model， 然后在表达层加入他的表现。然后model实现好了，系统也就实现好了。

维护上，如果需要重构，保持接口不变，改变model的实现。新的功能 就实现新的model并加入相关的表示。出bug就推断是哪个model的问题， 然后去修复。

可能的问题是model到最后非常的多，这说明了系统本身开始复杂了。

目前实现（有些model的实现还不完整）：

Section(99%) Board(99%) Post(99%) UserInfo(99%) Mail（99%） Disgest（99%）

以上是核心层，对应原始的直接的sql操作，不包括权限等复杂功能。

Online ReadMark

对应直接的redis操作。

UserAuth Permissions Action

胶水层，调用各个model同时运作。