我有一个NoteEntity
类,用于在我的notes
表中表示一行。一个"(数据)实体"在我的框架中严格表示存储/可存储的数据条目 - 如果您愿意,则表示数据库行。创建这样的对象与使用mysqli_fetch_array()
返回的数组初始化它一样简单,这要求我将对象属性与我的表的列名匹配。
继承自父DataEntity
类的构造函数:
PHP代码
public function __construct($row_array)
{
foreach ($row_array as $column => $value)
{
if (property_exists($this, $column))
{
$this->$column = $value;
}
else
{
trigger_error(get_class($this) . " has no attribute called '$column'.", E_USER_NOTICE);
}
}
}
如您所见,它所做的就是将相应的列映射到相应的对象属性。
这对我来说很好,因为NoteEntity
类只定义了一次,因此如果表列会发生变化,很容易改变其内部工作方式。但是,如果我不希望我的整个代码依赖于给定的表格,那么这也要求我对每个和每个属性使用getter方法。列名。
问题是:对每个房产都有一个吸气剂是好的做法,还是我应该调查另一种做法?我从性能角度问这个问题,但是我'我希望尽可能保持我的代码可维护。
我关注性能的原因是,如果它变得更加繁忙,快速获得属性:
PHP代码
foreach ($notes as $note_entity)
{
$template->Process(array(
'note_name' => $note_entity->GetName(),
'note_ext' => array_pop(explode('.', $note_entity->GetFilename())),
'subject_id' => $note_entity->GetSubjectID(),
'subject_name' => $note_entity->GetSubject(),
'institute_id' => $note_entity->GetInstituteID(),
'institute_nick' => $note_entity->GetInstitute(),
// ...
));
}
...对于几十个笔记可能没那么好,但是他们的计数预计甚至会在每个请求的千中,这会增加重要的函数调用开销。目前的版本非常使用方便,因为在编写列名时不需要代码的任何部分。
我提出的可能的解决方案包括返回关联数组中每个属性或每个属性的子集的方法。这有以下小的缺点:
NoteEntity
之间创建隐式逻辑依赖关系,如果所需子集在调用位置之间有所不同,则会使用它; 答案 0 :(得分:1)
我认为这更像是设计偏好,但使用getter / setter有许多优点。
封装和隐藏内部结构通常是很好的做法。互操作性是使用getter和setter是一个好主意的另一个原因(即,模拟变得更容易)。
是否要为基元执行此操作是有争议的,但通常您不希望通过直接引用属性来更新属性,尤其不是外部引用属性。因此,拥有getter / setter是绝缘的好方法。
您获得的优势远远大于您即将失去的表现。