我正在实现一个数据库搜索算法,该算法搜索MongoDB中的许多集合,并根据整个数据库的状态返回优化结果。我对实现没有任何问题,但命名法以及我应该如何构建文件系统是困扰我的。我应该在模型 - 视图 - 控制器模式中放置只读操作吗?这是一项服务吗?它有一个控制器,但我认为它不能满足成为模型的标准。
答案 0 :(得分:1)
模型视图控制器架构几乎相当于客户端服务器设置中的三层或四层解决方案,并且适用相同的规则。
复杂和密集的数据库功能与最适合该任务的工具一起使用并且最可重复使用,在这种情况下,我认为RDBMS将是绝大多数RDBMS中的最佳选择,因为它是RDBMS最了解如何操纵数据,制定查询计划等......
也可以说,从纯粹编码的角度来看,模型层将是最自然的地方,在这一点上,您可以在一个层中拥有所有数据访问权。
将此类功能放置在最不可重复使用的层(即控制器/视图)
中极不可能是有利的。这当然只是我的观点,我怀疑你会得到很多其他意见但是(对于我的生活来说,不能认为从性能的角度来看,yopur逻辑属于数据库级以外的任何地方
<强>更新强>
模型是所有数据的守护者。如果视图或控制器需要数据,它会向模型询问该数据。视图或控制器不应关心如何获取数据或从何处获取数据。这是关于分离关注点。这样就留下了问题。我是否将代码放在模型或RDBMS中查询数据库?
当然,你必须在模型中有一个方法让视图或控制器首先调用,所以当然你需要一个模型,但是那个方法内部和实际查询SQL所在的位置取决于设计师。关键是,只要查询存在于模型或数据库级别,您就会从视图或控制器中隐藏实现,并且可以随时随意更改实现,而不必担心调用它的可能位置。
所以模型或RDBMS就是答案。选择的解决方案取决于您使用的MVC工具和您正在使用的RDBMS。还要记住,模型不必包含一个单独的方法,这意味着您可能会从评论中略过这些方法。
答案 1 :(得分:1)
这个问题非常依赖于语言以及该语言中存在的功能。我将从PHP的角度讲。
搜索功能应该进入模型,模型作为MVC模式中的数据提供者备份。一个单一的中心点,可以从中自我实现。
一些MVC实现了所谓的factory
类。它们专门设计为位于MVC正常模式之外,以便能够提供数据:http://en.wikipedia.org/wiki/Factory_method_pattern。作为使用过这种模式的人,我可以说它很快变得复杂和无法管理。这就是为什么我更喜欢将模型备份为数据提供者本身,它只需要类组织。