我正在研究我的工作中的架构重新设计,我们基本上已经确定了一个松散基本的MVC自定义解决方案。目的是在我们的系统中的每个模型中定义标准CRUD操作和附加列表操作。
不幸的是,我们系统中大约30%的代码使用复杂的连接和其他不适合此模型的高级查询。也就是说它可以适合模型,但是列表函数会很大并且肯定容易出错,这是我们试图通过重写来解决的问题。
鉴于此,您会在这样的系统中放置复杂且非常具体的查询?我们一直在玩弄一些选择。
我们也有外包帮助,所以我们试图在实施和可维护性方面尽可能简单。 ORM解决方案或其他重量级人物是不可能的。
您希望将这些内容视为开发人员?
答案 0 :(得分:2)
我显然缺乏评论所需的特权,因此我将此作为答案张贴......
您能提供一些不符合模型的查询示例吗?一般来说:一个好的ORM会让你走得很远,但是有些查询真的太毛茸茸而且不容易映射,如果你的团队已经拥有强大的SQL技能,那么ORM似乎也会阻碍它。
答案 1 :(得分:0)
首先,你所有的疑问应该留在你的模特身上。 其次,大多数mvc框架为你的数据库操作提供的不仅仅是简单的crud,比如你可以传递查询字符串的查询功能,在这种情况下你可以手工构建你的查询或者像查询构建器那样构建你的查询Zend_Db_Table_Select并且可以很好地处理多个连接。或者,如果我们查看Zend之外的其他地方让我们说Codeigniter,它仍然为模型提供一个查询构建器,您可以在其中添加联接或构建任何其他类型的复杂查询。
有人说,看起来你是基础模型类(扩展你们每个人的模型)需要一个查询构建器功能,那么你应该都很好,因为你可以构建任何查询你喜欢你喜欢的任何模特。
答案 2 :(得分:0)
我在MVC框架中遇到了类似的问题,我从头开始构建。
我不特别喜欢SELECT *在复杂查询上的开销,所以我没有构建任何功能。
编码速度较慢,但我在相关类中手动编写每个查询(我的模型在99%的时间内调用了类)。
对于在各种例程中共享的非常复杂的查询,我有返回通用连接的函数,然后连接该特定查询的其他参数。
按要求提供的示例:
private function returnFindClientRequests(){
$query = "SELECT
SR.sign_project_name, SR.module_signregister_id_pk
,SRI.module_signregister_sign_id_pk,SRI.sign_location_address
,SRR.status, SRR.module_signregister_item_client_request_id_pk, SRR.client_comment, SRR.requested_by_user, SRR.date_created
,SRR.admin_comment, SRR.date_actioned
,CL.client_name, CL.module_client_id_pk
FROM
`module_signregister` SR, `module_signregister_item` SRI, `module_signregister_item_client_request` SRR, `module_client` CL
WHERE
SR.module_signregister_id_pk = SRR.module_signregister_id_pk
AND SRR.module_signregister_sign_id_pk = SRI.module_signregister_sign_id_pk
AND SRR.requested_by_group = CL.module_client_id_pk
AND " . Database::groupQuery('CL');
return $query;
}
此查询在其他一些函数之间共享,但也使用对我们用于将会话特定变量返回到许多查询的Database :: groupQuery()的调用。
答案 3 :(得分:0)
模型是工人 - 如果您有100份报告,则可能需要100个模型。联接与MVC无关 - 您的数据如何被解决是另一种模式。如果您没有使用ORM并且您没有使用活动记录,那么剩下的就是通过模型将SQL直接发送到服务器。可能通过专用的数据库类,但模型将处理查询及其结果。