【发布时间】:2011-06-22 18:03:49
【问题描述】:
作为previous question 的后续行动,我要求解决一个已损坏的问题,我试图找到一种以“可读”方式表达任意标识符的方法。
上下文:我们正在使用具有身份的实体(来自DDD的域模型对象)。此身份(映射到数据库主键)可以表示为字符串:'123'、'ABC'。
一些实体可以有一个复合身份,即由两个或多个其他实体的身份组成:array('123','ABC')。
有时,我们想要漂亮地打印这个身份,或者在只允许单个字符串的地方使用它(例如,在 HTML <option> 值中)。该过程必须是可预测和可逆的,即如何将其反转回其原始状态不应有歧义。
当我们想要人工读取这个身份时,出于调试目的,阅读123、ABC 或123~ABC 而不是a:2:{i:0;s:3:"123";i:1;s:3:"ABC";} 更容易,这就是我们不这样做的原因不想使用serialize()或json_encode()等内置函数。
json_encode() 做得很好,但是在 HTML 中使用它时,引号必须正确编码,它变得非常不可读:
<option value="["123","ABC"]">
我们可以在哪里使用像这样的好格式:
<option value="123~ABC">
当发布 HTML 表单时,我们必须能够将此编码的 identity 恢复到其原始状态:array('123','ABC') 以检索正确的 entity。
最后,如果 identity 包含除字母和数字之外的其他字符,则格式变得复杂(人工)阅读是完全可以接受的。
一些基本的例子:
'123' => '123''ABC' => 'ABC'array('123','ABC') => '123~ABC'(只是一个想法)
'string with non-alphanumeric, even non-àscìì char$' => ?
包含其他字符的字符串可以接受任何(或多或少复杂的)表示。结果字符串应该只包含 ASCII 字符,即使原始字符串包含非 ASCII 字符。整个过程必须是完全可逆的。
你知道怎么做吗?
【问题讨论】:
-
实体的有效字符是什么?
-
任何字符都对身份有效,因为它在数据库字符串主键中。但在现实生活中,大部分时间都是由可读字符组成的。这就是编码应该同时兼顾两者的原因。
-
那么你说的是哪个字符集?它可以用 Unicode 代码点表达吗?
-
好点。字符集应该无关紧要。如果原始字符串包含非 ASCII 字符,那么对它们进行编码以使其也适合 ASCII 字符集将是一个很好的解决方案。我更新了我的问题以反映这一点。
标签: php orm domain-driven-design identity identifier