设计问题：被老大毙掉的架构设计，请大家客观分析下，是否真的有重大问题，百分求教，50分给有道理的人，其他散给大家

[icoding]

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

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

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

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

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

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

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

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

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

[icoding]

批评的，肯定的都可以，只要说的有道理，楼主并不怕承认自己错了，谢谢各位

[图灵狗]

看了一下，楼主的思路还是蛮清晰的，如果说有问题的话，我倒是觉得应该把数据和显示分离，简单来说，就是书／知识点／页面它们本身的数据用树型结构进行管理，而至于如何去show和卷动完全是另外的事情，应该隔离开来，便于扩展和维护。

[一入程序深似海]

企业追求的是盈利。 老大不是技术走过来的话，貌似对设计这块不是很理解。 想要项目有扩展性，方便以后维护，就应该做一下设计并进行评估。 理论上，界面和业务逻辑应该分离，如2楼所说。

[tonforce]

楼主的思路已经够清晰了，设计的也很好！ 楼上几位达人的观点也很实在。 每个软件的设计，可扩展性非常重要 不过这要求对设计和业务都很精湛 俺就吃过这上面的亏，亏大发咯。 佩服下楼主。

[www_adintr_com]

我赞成你么老大的说法, 确实太复杂了, 那么多的类, 还要在内存里去构造 DOM.... 效率肯定不会高的. 如果你是一个 C++ 的本地应用, 这样设计不错, 但是对一个 PHP 的网页来说就不太适合了. 想想每访问一下页面你就要去解析一个 DOM 到内存里面, 然后再去渲染, 太耗资源了.

[赵4老师]

敏捷宣言：代码重于设计。

[srf0846]

楼主的对于书和知识点的组合模式很好，但是 数据在页面 的显示就不用这个模式 比较好，单独用AJAX和后台小函数解决，这样就把数据操作 和整个显示操作分开，比较好一点，个人意见 啊！

[wintree]

设计的不错，感觉就是有点麻烦 搞复杂了一样

[e_play]

过度设计及过早的考虑扩展性，也是初学者常犯的错误

[healer_kx]

当然被X了, 首先iOS上面，就不推荐用WebView那些东西Render HTML什么的， 这样的用户体验可能不够好。 另外你老大说的Ajax，服务端没什么逻辑，只负责数据的，基本和REST风格的现代服务器架构解决啊。 iOS上面最好还是用Native了。

[sniffer12345]

用phonegap吧，就一个掌上书库之类的，快速更新，快速开发才重要。你用native的话光下载图书封面的管理都够你头痛啦。 至于设计。。说实话换我是老大看你絮絮叨叨画这些UML我都烦。把数据结构订好，表入库了，剩下的跟楼上说的一样，架个restful的服务器，用ruby就敲个命令就都行了，连crud都不用写。交互用json。拉到客户端上边挨个绘上去，需要那么复杂吗？