我目前正在使用数据库设置页面对象的自定义框架中工作，该页面对象包含有关模块，视图，控制器等的信息，前端控制器使用它来处理MVC中的路由等（显然）模式。
处理数据库中页面的最初原因是因为我们需要能够在管理界面中动态创建新的登录页面，因为我们还需要创建onLoad和onUnload事件，其他动态对象可以附上。
然而，在昨天阅读了这个post之后，它让我想知道我们是否不应该将这个处理移出数据库并使其像其他框架一样进行所有文件结构和代码驱动，以便可以在没有测试的情况下测试页面让数据库成为一个组件。
我目前正在考虑是否要废弃自定义框架并使用其中一个标准框架并对其进行扩展（现在最有可能），但我想知道是否扩展框架以处理页面请求像我们现在这样的数据库，或者我们应该简单地使用框架附带的任何路由/处理机制？
答案 0 :(得分：3)
通常我对在“玩具”应用程序中允许的内容非常宽容，但我认为有一些不良习惯应该避免，无论如何。数据库是功能强大的工具，通过存储过程提供相当强大的语言，可以完成您需要做的任何事情......但它们确实应该用于存储和扩展数据访问，并强制执行低级数据一致性规则。
几年前，将业务逻辑放在数据层中很常见，但关注点的分离确实有助于应用程序在其生命周期内的可维护性。
请注意，使用数据库存储页面模板而不是文件系统没有任何问题。两者之间的界限将在未来进一步模糊，我有一个系统，所有模板都在数据库中，因为低预算托管问题以及需要如何保存动态生成的内容。只要您的框架可以轻松地从文件或字段中提取模板并处理它们，无论哪种方式都无关紧要。
另一方面，昨天的帖子是关于从数据库直接生成UI层元素 （至少，这是我如何阅读它），而不是模板的异常存储位置。 那是一个深层关注的原因......数据库被锁定到网络应用程序，只有网络应用程序。
另一方面，如果你的系统运行良好且易于扩展，那么永远不要把别人的建议太多地放在心上。每个用例都略有不同。如果您的可维护性没有受到影响并满足业务需求，那就足够了。