永远的MVC

• 无论你的代码是否显式的遵循 MVC 的方法, 她都存在.
• 无论你的代码是否违背了公认的 MVC 方法, 她都存在.

总之只要你写代码, 无论你怎么写, 她都存在.
对于一个运算表达式:

又或者对于一个函数:

• a 就是 view
• “+” 就是 controller

MVC在心中

• 类型声明, 包含 这个词
• 文件名, 包含 这个词
• 目录名, 包含 这个词

在名称上显示出来是好方法. 这增强了代码可读性, 一目了然.
当然如果目录名已经用了了, 目录之下的文件或者类型声明是否有必要再加上 , 语言不同, 习惯不同, 并没有定式. Go 语言一向提倡 能省则省.

依据 MVC 目录看起来是这个样子

典型的树状结构增强了代码可读性, 是常见 MVC 目录组织形式.

TypePress的方法

意思是尽量降低目录曾经深度, 视觉上不显示依赖关系. 事实上这类似于组件独立化.
如果代码是辅助性的, 例如服务器端的 Handler, 那就表现为独立的 Rep. 如果可以分组, 例如浏览器前端组件, 那就在同一个 Rep 下做扁平目录.

实验性想法, 目的是给应用生成工具提供基础支持.
对于具体应用, 比如博客, 业务层面的控制器, 多具有层级关系. 其中还涉及角色控制和 http Request Method. 用 martini.Router 写起来像这样

如果用自动注册路由写起来像这样

• github.com/UserName/RepName/Admin/GET/profile.go
• github.com/UserName/RepName/Admin.GET.profile.go

都是能被识别的写法, 依据大小写和”/“,”.”作为分割符号实现自动注册路由是可能的.
由此设计出自动构建/装配工具就有了基础.TypePress 将尝试这种方式.