设计问题：被老大毙掉的架构设计，请大家客观分析下，是否真的有重大问题

iCoding

原因：
在ipad上做一个类似于ibook的软件，其实相当于用webBrowser展现一套HTML页面（写了个JS框架控制内部数据的加载，所谓内部数据就是一套JSON文件和图片）

需求：
做一套生成他规定的内部数据的工具，要所见即所得，至少也要和他展现形式差不多的形式（HTML页面）进行编辑保存，PHP编写，支持导入导出

设计思路：
抛弃书先不谈（因为存储格式未定），理论上：页面和文本块，图片本身是树状结构，然后多个页面构成一个知识点，多个知识点构成一本书，从结构上看树状结构，如果要导入这样的数据进行编辑，那么我的思路是首先构造这样的树（在内存里）之后绘制他们

页面的绘制:
调用页面类的show方法。如果要绘制页面那么先构造一个页面的DOM树，之后往这个DOM树上挂载控件，给控件赋值（控件自己的show方法）

知识点的绘制：
一个知识点其实就是页集合，那么我会绘制第一个页面（show里调用第一个子对象的show），并在页面上添加一个导航条可以上下页滚动（调用指定页的show）

书本的绘制:这里直接调用知识点的show会有点问题，因为知识点的滚动需要一个导航条，页的滚动又要一个导航条，我有个不成熟的想法，如果这样，我可以让对象自己的show没有实现方法，使用一个show对象进行绘制，这样我就可以使同一个对象在不同的上下文里有不同的绘制方式

整体上看，就是一个组合设计模式，一个解析器，一个DOM操作对象（用接口封装，使得可以透明的选择不同第三方的库）

结果：
老大觉得，你丫这么麻烦干嘛，写一个操作界面，每个操作用ajax解决，服务端不要架构，用各个小函数解决

问题：请大家客观分析真的有问题吗？

群雄逐鹿中原

觉得你们老大是对的，

其一你的实施成本太高，怕实现不出来
其二怕你做出来了，别人无法卫华
其三html本来就是超链接和结构化的，服务器端再一层结构，徒添麻烦

windoze

严重赞同你们老大的思路，谁说书是个树状结构来着？谁说书里只有页面和文本块的？直接点，谁知道你们要做的到底是不是书来着？一个客户端渲染引擎加上服务端，你想干什么不可以啊。
你的方案显然过度设计了，其实我的经验是，但凡有人画UML图，那他一定想太多了。

starwing83

我也赞同你老大的设计：你们现在连书本是什么结果都没搞清楚呢，你就假设书本是树结构？万一是图结构呢？假设是魔鬼啊！

而且，简单的设计就是好的设计，你的【需求】就仅仅是页面导航，仅仅是两个链接（一个向前，一个向后，充其量一个列目录），你搞那么多虚的放内存里面干嘛？

linux_c_py_php

楼主能不能有点模块化思想, 都混在一起.

wlmouse

建议你看看现在开放的电子书源文件格式吧。
无论是LaTex还是docbook，都是怎么做的。你们现在把内容和展现搞在一起，有点修改变化就等哭吧。更不用说输出多种格式了。

sonicling

楼主是在做排版工具。

flw

我都没看懂楼主的文章，
估计楼主的老大觉得复杂也是因为没看懂。

三句话能说清楚的东西，能不能别这么罗嗦？
而且语文功底也不好，错误一堆一堆的。

孙轩

建议先搞清楚书是什么存储格式再做设计,都不知道杀猪杀虎,怎么搞

wlmouse

我的建议是不要随便自定格式，尽量使用现有开源标准。而且存储的原始格式一定是纯文本。
所见即所得在这里我认为是邪道。