台灣最大程式設計社群網站
線上人數
614
 
會員總數:242468
討論主題:187511
歡迎您免費加入會員
討論區列表 >> PHP >> 新的class中會使用到資料庫class該如何處理?
[]  
[我要回覆]
1
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
新的class中會使用到資料庫class該如何處理?
價值 : 30 QP  點閱數:212 回應數:8

樓主

碰器
門外漢
0 1
28 2
發送站內信

目前在程式架構上遇上了一些瓶頸,
想麻煩前輩們給些指點。

目前參考tkdmaf大的教學新建了一個關於PDO拓展的class
https://www.youtube.com/watch?v=CfmYngJX1KA
這個class使用是去new一個物件來使用,
想請問如果我想要新增一個class是有關商業邏輯會使用到資料庫,
我該如何處理比較好?
1.在新類別的開頭require_once('PDO拓展class'),再new一個資料庫物件來使用。
2.以後的每個商業邏輯類別會用到資料庫都繼承PDO拓展class。
3.....
目前想到的處理方法都很怪,
要讓程是跑是沒有問題的,
只是想請問在正常OOP的程式架構,
我應該如何處理新的商業邏輯class?


搜尋相關Tags的文章: [ php ] , [ class ] ,
本篇文章發表於2018-04-29 23:24
別忘捐VP感謝幫助你的人 新手會員瞧一瞧
1樓
回應

可樂快跑
檢舉此回應
擴展的class本身是基於基礎class的延伸。
就這一點來說他就已經具備原始class的功能了。

只是我覺得你敘述問題有點……不是很明確。
如果你是基於每一次都要做require_once然後再new物件這件事覺得麻煩的話。
那你等同於是要重新架構你整套的環境…………該說那你就等同於是要寫framework………該說那還不如直接使用Laravel比較快一點。

我的PDO影片只是一個基本性質的教學。
要怎麼活用他還是要看個人對PHP各方面理解到怎麼樣的層面而定。
事實上在一些framework中,pdo也只是他們展示資料的底層而已。
像是CodeIgniter的Active Record,底層可以選mysql、mysqli、PDO
Laravel的Elquent ORM我倒是沒仔細研究過他的底層設置(該說是太好用了所以沒去關注),不過不是mysqli就一定是PDO

我其實覺得如果對這方面真的很有興趣,可以參考CodeIgniter的Active Record或是Laravel 的Elquent ORM他們的實際使用方式。

本篇文章回覆於2018-04-30 09:59
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
2樓
作者回應

碰器
檢舉此回應
這是我實作前輩的class



這是我接下來根據功能性會做幾個類似的calss



這個是我的主頁面,呼叫功能性的class去實作



想請問前輩這樣的做法是對的嗎?


本篇文章回覆於2018-04-30 10:30
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
3樓
回應

可樂快跑
檢舉此回應
基本上到這個階段我只能說你還只是基本的(小型orm的核心擴展)
這個影片我沒有說明的是,這只是基於一個擴展來擴充基本層面的東西。
這麼說好了。
我們可能常常會提到MVC架構。
當中的M(Model)指的是資料或邏輯(模型)
然後在Model中常被使用的資料庫其源頭就是來自底層方法的實現。
不過不要誤會的是,你做的東西就只是個底層,還談不上Model。
但是,如果你的功能性的東西是要能連續被動覆使用的。
你應該要寫成Model,然後你的Controller去呼到這個Model,而不是呼叫你的資料庫底層。
本篇文章回覆於2018-04-30 10:46
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
4樓
作者回應

碰器
檢舉此回應
前輩首先謝謝你的回答

我反覆思考你的解說,
我想釐清我的了解有沒有錯誤,
商業邏輯應該是寫在Model裡,
而不是在class裡,
如果在未使用mvc框架下也無自行實作mvc,
那我是否應該將邏輯分類成幾個php
裡面單個phph會有邏輯,class,資料庫讀取這些。

另外想用一個例子請教
A:



B:


想請問A或B的處理哪個比較好?
本篇文章回覆於2018-04-30 13:37
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
5樓
回應

可樂快跑
檢舉此回應
我給你一個想法:



你思考看看怎麼實踐出這樣的作法。

用法上很類似Elquent ORM或是Mobile Device用的Realm。

至於好與不好或是那個好這個我不能告訴你那個好。
因為每個人都有自己的想法和習慣,以及面對不同的狀態和環境而有不同的需求。
本篇文章回覆於2018-04-30 15:12
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
6樓
回應

迷路
捐贈 VP 給 迷路 檢舉此回應
我的做法是在自訂物件外面建立資料庫物件
然後把這個資料庫物件做為自訂物件的屬性
通常是在建構子的部分就以參數的型式傳入建立
本篇文章回覆於2018-05-02 09:41
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
7樓
回應

浩瀚星空
捐贈 VP 給 浩瀚星空 檢舉此回應
其實我倒是覺得,或許有個地方都錯了。
pdo是一個公開內置物件。
其實如果今天是想要自建一個物件來做其pdo的控制。
實際上,根本不需要去繼承pdo處理才對。

正常來說,一般的db物件,使用的方式大多是內子物件(如pdo、mysql、mssql....)
由於資料庫的物件是屬於內置物件。它雖然是物件,但不需要有所謂的繼承的寫法才對。
當然了,是否需要繼承的用法,這的確是見人見智了。

我個人並不會特別去將pdo外接一些特規的東西出來。一個沒搞好,會將原來的pdo給處理掉。
基本上我也是會往自訂物件的方式來處理。
本篇文章回覆於2018-05-02 14:59
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
8樓
回應

可樂快跑
檢舉此回應
#星空
你講的那部份是對的。
但是我那個只是用於擴展的教學。(順便教繼承)
實務上的用法是將pdo作為委派的實體來使用。不用去繼承後修改功能。

畢竟……繼承的話也是要還債的。
本篇文章回覆於2018-05-02 17:32
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
   
1

回覆
如要回應,請先登入.