問題描述
我正在構(gòu)建一個(gè)用于學(xué)習(xí)/實(shí)驗(yàn)和小型項(xiàng)目的小型 MVC 框架.我需要找出模型內(nèi)部的基礎(chǔ)知識(shí)，因?yàn)橐粋€(gè)完整的 MVC 框架和 ORM 對(duì)于僅僅幾個(gè)數(shù)據(jù)庫調(diào)用來說是多余的.
I'm building a tiny MVC framework for learning/experimenting and small project purposes. I needed to find out the basics of the internals of the Model since a full MVC framework and ORM is overkill for just a few database calls.
Class Model
{
}
使用空類時(shí)，我必須在何處調(diào)用 new PDO 對(duì)象以進(jìn)行數(shù)據(jù)庫調(diào)用?
Using an empty class where would I have to call a new PDO object for database calls?
在模型內(nèi)部調(diào)用查詢會(huì)是什么樣子?
What would calling a query look like inside the Model?
此外，我在哪里可以找到 MVC 的初學(xué)者網(wǎng)絡(luò)/書籍資源(包含大量示例代碼)?我聽說過很多術(shù)語，例如業(yè)務(wù)邏輯和數(shù)據(jù)庫邏輯.我記得在某處讀到您應(yīng)該將業(yè)務(wù)邏輯和數(shù)據(jù)庫邏輯分開.我可以稍微理解這個(gè)概念，我只是想知道它是什么樣子或它們?cè)诖a本身中的含義.我很困惑如何將業(yè)務(wù)邏輯和數(shù)據(jù)庫邏輯分開但仍然在模型內(nèi)部.
Additionally, where can I find a beginner's web/book resource to MVC (with lots of example code)? I've heard a lot of terms such as business logic and database logic. I remember reading somewhere that you should separate business logic and database logic. I can understand the concept somewhat, I just wonder what it looks like or what they mean in code itself. I'm confused how business logic and database logic should be separated but still be inside the Model.
我主要是在尋找代碼/邏輯示例作為答案，可能除了后一段.
I'm mostly looking for code/logic examples as answers, except maybe the latter paragraph.
推薦答案
警告:
此帖子中的信息非常過時(shí).它代表了我對(duì) MVC 模式的理解，因?yàn)樗?2 年前的.當(dāng)我解決它時(shí)，它會(huì)更新.大概是這個(gè)月(2013.09).
該死的！(2017.11).
Warning:
The information in this posts is extremely outdated. It represents my understanding of MVC pattern as it was more then 2 years ago. It will be updated when I get round to it. Probably this month (2013.09).
Damn it! (2017.11).
Model 本身不應(yīng)包含任何 SQL.曾經(jīng).它旨在僅包含域業(yè)務(wù)邏輯.
Model itself should not contain any SQL. Ever. It is meant to only contain domain business logic.
我建議的方法是將并非嚴(yán)格意義上的業(yè)務(wù)邏輯"的職責(zé)分離成另外兩組結(jié)構(gòu):域?qū)ο?和數(shù)據(jù)映射器.
The approach i would recommend is to separate the responsibilities, which are not strictly "business logic" into two other other sets of constructs : Domain Objects and Data Mappers.
例如，如果您正在制作博客，那么模型將不會(huì)是 Post.相反，模型很可能是 Blog ，并且該模型將處理多個(gè) Domain Objects:Post、Comment、User 和其他對(duì)象的多個(gè)實(shí)例.
For example, if you are making a blog, then the Model will not be Post. Instead most likely the model will be Blog , and this model will deal with multiple Domain Objects: multiple instances of Post, Comment, User and maybe other objects.
在您的模型中，域?qū)ο蟛粦?yīng)該知道如何將自己存儲(chǔ)在數(shù)據(jù)庫中.或者甚至注意任何形式的存儲(chǔ)的存在.這是Data Mappers 的責(zé)任.您應(yīng)該在模型中做的就是調(diào)用 $mapper->store( $comment );.并且數(shù)據(jù)映射器應(yīng)該知道如何存儲(chǔ)一種特定類型的域?qū)ο?，并贏得將信息放在哪個(gè)表中(通常單個(gè)域?qū)ο蟮拇鎯?chǔ)實(shí)際上會(huì)影響多個(gè)表).
In your model, the domain objects should not know how to store themselves in database. Or even be aware of the existence of any form of storage. That is a responsibility of Data Mappers. All you should do in the Model is to call $mapper->store( $comment );. And the data mapper should know how to store one specific type of domain objects, and win which table to put the information ( usually the storage of of single domain object actually affects multiple tables ).
(僅來自文件的相關(guān)片段):
(only relevant fragments from files):
- 我假設(shè)您知道如何編寫一個(gè)好的構(gòu)造函數(shù) .. 如果您有疑問，請(qǐng)閱讀 這篇文章
- 示例中沒有命名空間，但應(yīng)該是
- 示例中以
_開頭的任何內(nèi)容都是protected
- I assume that you know how to write a good constructor .. if you have doubts, read this article
- nothing is namespaced in example, but it should be
- anything that begins with
_in example isprotected
來自/application/bootstrap.php
/* --- snip --- */
$connection = new PDO( 'sqlite::memory:' );
$model_factory = new ModelFactory( $connection );
$controller = new SomeController( $request , $model_factory );
/* --- snip --- */
$controller->{$action}();
/* --- snip --- */
- 控制器不需要知道數(shù)據(jù)庫連接.
- 如果要更改整個(gè)應(yīng)用程序的數(shù)據(jù)庫連接，則需要更改單行
- 為了改變模型的制作方式，你創(chuàng)建了不同的類來實(shí)現(xiàn)與 ModelFactory 相同的接口
來自 /framework/classes/ModelFactory.php
/* --- snip --- */
class ModelFactory implements ModelBuilderInterface
{
/* --- snip --- */
protected function _prepare()
{
if ( $this->_object_factory === null )
{
$this->_object_factory = new DomainObjectFactory;
}
if ( $this->_mapper_factory === null )
{
$this->_mapper_factory = new DataMapperFactory( $this->_connection );
}
}
public function build( $name )
{
$this->_prepare();
return new {$name}( $this->_object_mapper , $this->_data_mapper );
}
/* --- snip --- */
}
- 只有數(shù)據(jù)映射器會(huì)使用數(shù)據(jù)庫，只有映射器工廠需要連接
- Model 的所有依賴都注入到構(gòu)造函數(shù)中
- 應(yīng)用程序中的每個(gè) DataMapper 實(shí)例都使用相同的數(shù)據(jù)庫連接，沒有 全局狀態(tài)(視頻) 必需.
文件 /application/controllers/SomeController.php
/* --- snip --- */
public function get_foobar()
{
$factory = $this->_model_factory;
$view = $this->_view;
$foo = $factory->build( 'FooModel' );
$bar = $factory->build( 'BarModel' );
$bar->set_language( $this->_request->get('lang') );
$view->bind( 'ergo' , $foo );
/* --- snip --- */
}
/* --- snip --- */
- 控制器不知道模型創(chuàng)建細(xì)節(jié)
- controller 只負(fù)責(zé)接線和改變?cè)氐臓顟B(tài)
文件 /application/models/FooModel.php
/* --- snip --- */
public function find_something( $param , $filter )
{
$something = $this->_object_factory('FooBar');
$mapper = $this->_mapper_factory('FooMapper');
$something->set_type( $param );
$mapper->use_filter( $filter )->fetch( $something );
return $something;
}
/* --- snip --- */
- 域?qū)ο筘?fù)責(zé)驗(yàn)證給定的參數(shù)
- view 接收并決定如何呈現(xiàn)它
- mapper 獲取對(duì)象并將所有必需的信息從存儲(chǔ)中放入其中(它不一定是 DB ..它可以從某個(gè)文件或外部 REST API 中獲取)
我希望這能幫助您理解 DB 邏輯和業(yè)務(wù)邏輯(實(shí)際上也是表示邏輯)之間的分離
I hope this will help you understand the separation between DB logic and business logic ( and actually , presentation logic too )
模型永遠(yuǎn)不應(yīng)該擴(kuò)展數(shù)據(jù)庫或 ORM，因?yàn)槟Ｐ筒皇撬鼈兊淖蛹?通過擴(kuò)展一個(gè)類，您聲明它具有超類的所有特征，但有少數(shù)例外.
Model should never extend Database or ORM, because Model is not a subset of them. By extending a class, you are declaring that has all the characteristics of the superclass, but with minor exceptions.
class Duck extends Bird{}
class ForestDuck extends Duck{}
// this is ok
class Table extends Database{}
class Person extends Table{}
// this is kinda stupid and a bit insulting
除了明顯的邏輯問題外，如果您的模型與底層數(shù)據(jù)庫緊密耦合，則會(huì)使代碼極難測(cè)試(談?wù)?單元測(cè)試(視頻).
Besides the obvious logic-issues, if your Model is tightly coupled with underlaying Database, it makes the code extremely hard to test (talking about Unit Testing (video)).
我個(gè)人認(rèn)為，ORM 在大型項(xiàng)目中是無用的，甚至是有害的.問題源于這樣一個(gè)事實(shí)，即 ORM 試圖彌合兩種完全不同的解決問題的方法:OOP 和 SQL.
I personally think, that ORMs are useless and in large project - even harmful. Problem stems from the fact that ORMs are trying to bridge two completely different ways of approaching problems : OOP and SQL.
如果您使用 ORM 開始項(xiàng)目，那么經(jīng)過短暫的學(xué)習(xí)曲線后，您可以非?？焖俚鼐帉懞?jiǎn)單的查詢.但是當(dāng)您開始遇到 ORM 的局限性和問題時(shí)，您已經(jīng)完全投入到 ORM 的使用中(甚至可能雇用了新人，他們非常擅長您選擇的，但在普通SQL).您最終會(huì)遇到每個(gè)與數(shù)據(jù)庫相關(guān)的新問題都需要越來越多的時(shí)間來解決的情況.如果你一直在使用基于 ActiveRecord 模式的 ORM，那么問題會(huì)直接影響你的模型.
If you start project with ORM then, after short learning curve, you are able to write simple queries very fast. But by the time you start hitting the ORM's limitations and problems, you are already completely invested in the use of ORM ( maybe even new people were hired , who were really good at your chosen , but sucked at plain SQL ). You end up in situation where every new DB related issue take more and more time to solve. And if you have been using ORM based on ActiveRecord pattern, then the problems directly influence your Models.
鮑勃叔叔 將此稱為技術(shù)債務(wù)".
Uncle Bob calls this "technical debt".
與主題松散相關(guān)
- 企業(yè)應(yīng)用架構(gòu)模式
- 敏捷軟件開發(fā)、原則、模式和實(shí)踐
- SQL 反模式:避免數(shù)據(jù)庫編程的陷阱
- PHP 面向?qū)ο蟮慕鉀Q方案
- PHP 實(shí)戰(zhàn)
這篇關(guān)于在 MVC 應(yīng)用程序中從模型正確調(diào)用數(shù)據(jù)庫?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！