| Event ID | Start | End | Status | Created_By | ----------------------------------------------------------------------------- | 12345678 | 2009-10-01 12:00:00 | 2009-10-01 12:15:00 | booked | John Doe | | 12345679 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | booked | John Doe | | 12345680 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | tba | Jane Doe |
用户可以从View中影响列显示,排序和排序.客户端可以拒绝/允许访问列并将列内容限制为特定值.用户无法覆盖客户端设置.用户是演员,而客户端基本上只是一个过滤器,它为属于客户端的用户创建可用数据的子集.用户和客户端设置保持不变.
我目前的方法大致如下：
Request --> Controller
| <--> sanitizes and returns Request params
| ---> Facade (capsules steps to fetch View Data)
| | <--> Table Data Gateway builds Query for requested View
| | <--> Query Decorator¹ applies User/Client settings
| | <--> DB Adapter fetches RecordSet from decorated Query
| <----returns Recordset
| <--> applies RecordSet to View
| <--> Data-Aware ViewHelper render RecordSet (and View)
Response <--returns rendered View
¹查询装饰器可以读取持久化的用户/客户端设置,并将其添加到TDG即时返回的基本查询对象中.
然而,最近我一直怀疑这种方法,并希望改进它.我想我可以完全删除TDG并使视图构建从UI完全通用;仅基于DB结构.用户肯定会喜欢这个.问题是,View必须对数据有很多了解. ViewHelpers必须知道列名以丰富数据,并且通常它们是关于Recordsets中的多个列的.它们不能是通用的,有些东西告诉我这无论如何都是麻烦.感觉就像混蛋.我无法确定原因.
任何模式,想法和意见都非常感谢.我知道这个问题有些模糊,但就像我说的那样,我无法确定是什么让我怀疑这种方法.所以我想我正在寻找以可维护的方式构建用户和客户端可定制数据库中心应用程序的任何良好实践方法.我当然不需要一个解决方案,只需要一些想法和一些链接来了解其他人如何解决这个问题,所以我可以在下一次重构时将其考虑在内.
注意
在接受答案之前,我会将问题保持开放状态.任何输入都表示赞赏.
您的“MVC”中缺少“M”.
此时,您手工制作了一个关系数据库模式,使其与您的域模型具有1：1的映射关系.这很棒,它使映射非常容易,但记录集仍然不是域类.
MVC上下文中的术语“模型”是指域模型,而不是关系模型.如果您有支持此应用程序的关系数据库,那么您需要某种映射.这并不是说你需要一个像Doctrine这样的完整ORM框架 – 虽然我发现这些工具让我的生活变得更加轻松,即使对于小型项目 – 但你需要一些东西.实际上,Zend Framework甚至详细介绍了在Quick Start中映射域模型的细节.
我认为您不需要删除TDG.抽象很好.为了让你的应用程序更加精简,我可以比较一下,进入办公楼并撕掉电话系统,理由是员工可以使用他们的手机.它们可以,但您不希望它们,就像您不希望您的视图直接在数据库中抛出SQL查询一样.它效率低,通常难以管理.
我的架构版本看起来像这样：
Request --> Controller
| <--> sanitizes and returns Request params
| ---> Facade (encapsulates steps to fetch View Data)
| | <--> Table Data Gateway builds Query for requested View
| | <--> Query Decorator applies User/Client settings
| | <--> DB Adapter fetches RecordSet from decorated Query
*** | | <--> Mapping layer converts RecordSet to Domain Model
*** | <----returns Model
*** | <--> applies Model to View
*** | <--> Data-Aware ViewHelper render Model (and View)
Response <--returns rendered View
我用***标记了更改行.实际上,我唯一改变的是,它不是从外观中拾取记录集,而是拾取模型(可能是一个域类数组),并将其应用于View.
您可以在View [Helper]中使用$row [‘Status’]这样的术语,而不是$event->状态,这样可以更长久地维护更安全,更简单.那里没有列名,只是一个属性.
现在你在问题的最上面明确提到你没有任何ORM,所以我想你可能已经意识到这一点,也许只需要推动.那些令人唠叨的疑惑可能与你的想法有关：如果它不总是只读的话怎么办？如果数据模型变得更复杂怎么办？如果人们开始要求更复杂的报告怎么办？
所有这些都是你拥有域模型的原因,为什么它实际上是MVC的基本构建块：最终,用户拥有的心智模型将与数据模型不同步,原因有多种,我不会进入这里.关键是,它几乎总是发生.
我确定这是必要的吗？我是否肯定这不仅仅是矫枉过正,一堆仪式咒语对于这么小的项目毫无意义？
不,我不是.只有你可以决定.我可以告诉你的是,如果没有合适的域模型,作为特定架构的MVC范例对你没有多大帮助.它有点好,但没有比在每个页面中使用内联查询或外观调用更好.没有模型,MVC只不过是一个花哨的URL重写方案.
也许你需要这种抽象层次,也许你不需要;但我猜你可能怀疑你可能,否则你不会问这个问题.考虑一下,分析当前的需求和范围,问问自己可能会发生什么样的变化,如果当前的体系结构看起来太脆弱而无法适应,那么下一个逻辑步骤将是域模型 – 即使今天它只是一个确切的关系模型的镜像.明天它可能不会.
希望这是你正在寻找的那种答案！