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