WEBプログラミングアーキテクチャ改革に関する予備的検討

長い間、プログラミング MVC アーキテクチャは人々の心に深く根付いてきました。プログラミング言語の継続的な進歩と開発に伴い。このアーキテクチャは決して進歩していません。私たちは MVC モデルを VC モデルに大胆に進化させようとしています。 [注意してください] 私は進化を使用しています。これは、最初に MVC、次に VC を意味します。ダイレクトVCモードではなく。

繰り返しますが、これは MVC モデルが悪いと言っているわけではありません。実際には、さらに進化する可能性があります。 MVC パターンに慣れていないと、VC パターンを理解できません。
Model の明らかな省略は、プログラミング言語の進化の結果です。退化するというよりも。これにより効率が大幅に向上します。 。 。

1. モデルの前提条件を省略します。
2. モデルの実装を省略します。
3. モデルを省略することの強力な利点。
4. モデルの省略によって失われた機能をどのように補うか?
5. この VC アーキテクチャ用の PHP フレームワークの実装。
上記の機能は以下に徐々に追加されます...
ここで提案があります。アドバイスをいただければ幸いです。 。 。 。
フォローしていただきありがとうございます。 。 。 。

ディスカッション（解決策）に返信

まずレンガを投げる: あなたは MV に退化しました

まずレンガを投げます: あなたは MV に退化しました

[気をつけてください]、私は最もよく使います重要なのは進化です。最初に MVC があり、次に VC があります。ダイレクトVCモードではなく。

まずレンガを投げておきます。あなたは MV に退化しました

[注意してください]、私は進化を使用しています。これは、最初に MVC、次に VC を意味します。ダイレクトVCモードではなく。 』
大まかな概要を述べましたが、具体的にはどうすればよいでしょうか？

WEBプログラミングアーキテクチャ改革に関する予備的考察

長い間、プログラミングMVCアーキテクチャは人々の心に深く根付いてきました。プログラミング言語の継続的な進歩と開発に伴い。このアーキテクチャは決して進歩していません。私たちは MVC モデルを VC モデルに大胆に進化させようとしています。 [注意してください] 私は進化を使用しています。これは、最初に MVC、次に VC を意味します。ダイレクトVCモードではなく。

繰り返しますが、これは MVC モデルが悪いと言っているわけではありません。実際には、さらに進化する可能性があります。 MVC パターンに慣れていないと、VC パターンを理解できません。
Model の明らかな省略は、プログラミング言語の進化の結果です。退化するというよりも。これにより効率が大幅に向上します。

1. モデルの前提条件を省略します。
1) モデルとは何かを知らなければなりません。モデルはデータベース操作層であり、データベースを扱う関連操作を担当します。 (非常に詳細な DB ドライバー層はここでは省略します)、一般的に使用されるデータベース操作方法がオブジェクト化されています。コントローラー層ではデータベースを直接操作する必要がなく、ビジネスロジックとデータ処理が分離されます。プログラムの拡張とメンテナンスに役立ちます。
2) モデル層は非常に重要であるのに、なぜ省略されているのでしょうか? これらの利点はすべて失われているのではないでしょうか?
2. モデルの実装を省略します。
1) まず、モデル層の欠点について説明します。MVC モードでは、さまざまなクラス間の呼び出しが複雑すぎるため、ファイルが頻繁にロードされます。これは、PHP フレームワークにおける MVC モードの悪影響です。速度が遅すぎます。 Java と同様に、大砲を使用すると蚊を殺すことができます。これにより、呼び出されるクラスが多すぎることが定量的から定性的に変化するという 2 つの問題が生じます。 TP3.2 など、フレームワーク プログラムは非常に複雑になっています。次に、ロードされるカテゴリが多すぎるため、プログラムの速度が非常に遅くなり始めます。プログラム速度のボトルネックは DB からフレームワークに変わりました。
2) M層がもたらすデメリットを回避しながら、M層がもたらす利便性を享受できる解決策はあるのか？調べてみると、こんな方法があることが分かりました。これは、TP のモデル層に似ています。データベース操作を完全に方法化します。ユーザーは SQL ステートメントをまったく作成せずにデータベースを操作できます。もちろん、TP の多くの Model メソッドは単純ではなく、十分に確実ではありません。たとえば、Join メソッドです。カプセル化の余地もあります。

3. 具体的な実装:
1) DB クラス -> コントローラー基本クラス。
2) DB クラスは、もちろんデータベース操作をカプセル化します。コントローラーがDBクラスを呼び出します。クライアントが DB を便利に操作するために必要なすべてのメソッドを実装します。たとえば、where、orderby.count、join、joinUser、joinOwer などです。
3) ユーザー UserControler は基本クラス Controller を直接継承し、データベース操作は基本クラス Controller を通じて直接実装されます。 UserControler は独自のビジネス ロジックを管理するだけで済みます。
4) Model の関数は実際には透過的にされ、基本クラスの Controller によって省略されます。基本クラス Control が強力すぎるためです。
4. モデルを省略することの強力な利点。
1) まず、層がシンプルになり、呼び出しクラスが減り、プログラムがシンプルになり、高速化されますが、モデル層が提供する機能は全く減らず、むしろ増えています。
2) コントローラー層とモデル層が 1 つに結合されるため、次のような利点があります。コントローラはデータベースをステップごとに直接操作できます。手順の途中でプラグインを作成できます。また、プラグインは、基本クラスのコントローラー、またはコントローラーから継承されたサブクラスに統合できます。他のサブクラスによって呼び出されます。
3) 例: ページングおよび検索プラグイン: フロントエンドとバックエンドで 1 行のコードを記述する必要がほとんどなく (インストール コードの数行をコピーするだけ)、非常に強力で複雑な専門的な検索およびページング機能を実現できます。 。あらゆるWEBページに適用されます。これは、モデル層を省略することで実現されます。両方でなくても1つになります。このプラグインを実装する方法はありません。
4) スピードについて。データベースへの接続はLazyを利用した必要なときの接続や、共通のデータキャッシュ機能を利用するため、プログラミングに無駄がありません。
5. モデルの省略によって失われた機能をどのように補うか?
実際: 一部の関数はビジネス ロジックでもデータ処理でもない場合があります。現時点では、この関数をカプセル化してクラス ライブラリに変換し、必要に応じて呼び出すことができます。

6. この VC アーキテクチャ用の PHP フレームワークの実装。
1. コントローラー基本クラス: DB (mysqlDB) クラスを呼び出します。このメソッドを通じて、クライアントは SQL ステートメントなしでメソッドを呼び出すことができるため、データベースの操作が容易になります。
2. クラスを表示します。テンプレートタグの解析を実装します。
3. 単一エントリのindex.php フレームコントローラーVC関数を実装します。
7. 実践: 3 日間で、ステップ 6 で説明したフレームワークの機能を完全に実現します。このフレームワークは、会社の実際のプロジェクト プログラミングの開発に半月以上使用されています (チームの数名がこのフレームワークを使用してプログラミングしています)。結果:
1) 学習コストは約 20 分、長くても 1 時間以内です。
2) プログラミングの実装は TP3.2 関数とほぼ同じですが、コードはより単純です (書き込み、保守、読み取り)。
3) 継承されたクラスのコントローラーでは、ほとんどのメソッドのビジネス ロジック部分には数行のコードしかありません。 20行を超えるものはほとんどありません。モデル層を省略しても、コントローラー層のコード量はまったく増加しないことがわかります。
4) 同じプログラム速度は TP3.2 よりも 5 倍以上高速です。

ここではいくつかのアイデアを投げかけているだけなので、専門家がアドバイスをくれることを願っています。この記事を書く目的は、他の人がこのプログラムを理解していないと一般的に言うのではなく、一部の専門家が欠点を指摘してくれることを期待することです。言い換えれば、一歩後退です。私にはさまざまなプログラミング言語で数十万行の経験があります。私はこの業界に10年以上携わっていますが、まだ模索中です。
何千人もの人が参加する PHP 専門家コミュニケーション QQ グループ: 317172514。著者とコミュニケーションを取りたい場合は、このグループに参加して WEB プログラミングについて話し合ってください。

このような進化があります。座って、オリジナルのポスターが彼の意見を表現し続けるのを見てください。

MVC の M は主にデータベースまたはビジネス ロジックを扱います。
もっと簡単に言うと、Cさんをビジネスマン、Vさんを顧客、Mさんをメーカーと考えてみましょう。メーカー（M）がキャンセルした場合、事業者（C）がメーカー（M）の責任を負うことになります。ステップが省略されているように見えますが、実際には M がなければ、C でのみ処理されるすべての業務を解決するために、それに代わる別の製品が必然的に発生します。もちろん、M の代わりに C を使用したり、M を置き換える別のソリューションを使用したりすることもできます。これにより、C の負担も増加し、コードがより複雑になり、コードの再利用性が相対的に低下します。一部のデータベース操作メソッドは Thinkphp にカプセル化されていますが、M の代替にはならない場合があります。

個人的な意見、気に入らない場合は批判しないでください~~~

モデルはデータベース操作層ですか? ? ?
このビューは狭すぎます。モデルはビジネス ロジックであり、もちろんデータベース操作も含まれます。
TP が自動的に完了する部分に混乱します。
実際、TP には完全なものがあります。モデル スケジューリング ソリューションのセット。データベースアクセスをデモンストレーションとして使用する理由は、ビジネスロジックが何であるかを知ることは不可能であり、DESCRIBEコマンドを使用することで簡単にデモンストレーション用のクラスを構築できるためです。また、具体的なデータがあるため、その用途を直感的に説明できます。しかし、すべての
C がもともと M と V の間のブリッジであるわけではありませんが、MVC 間に明確な役割分担がないため、多くの場合、M に属するコードが C に入れられます
M 全体を C に入れたいだけです、それはいわゆる VC です
しかし、何はともあれビジネス ロジックが最初に来るので、M と C の混合物は M と呼ばれるべきです

投稿者はデータベース以外のビジネス ロジック操作のみを考慮しています。モデルはどこに置くべきですか?

ポスターにはすでにそのようなフレームワークがあるので、それを共有してみんなに学んでもらいましょう。

MVC の M は主にデータベースまたはビジネス ロジックを扱います。
もっと簡単に言うと、Cさんをビジネスマン、Vさんを顧客、Mさんをメーカーと考えてみましょう。メーカー（M）がキャンセルした場合、事業者（C）がメーカー（M）の責任を負うことになります。ステップが省略されているように見えますが、実際には M がなければ、C でのみ処理されるすべての業務を解決するために、それに代わる別の製品が必然的に発生します。もちろん、M の代わりに C を使用したり、M を置き換える別のソリューションを使用したりすることもできます。これにより、C の負担も増加し、コードがより複雑になり、コードの再利用性が相対的に低下します。一部のデータベース操作メソッドは Thinkphp にカプセル化されていますが、M の代替にはならない場合があります。

個人的な意見、気に入らない場合は批判しないでください~~~

これはあなたの過去の理論です、はい、今ではプログラミング言語はphpなど進化しています。モデル層を省略します。 Cさんの負担は全く増えず、むしろ減りました。実際にプログラミングした結果がこれです。

次のコードは、コントローラーにカスタマー サービスを追加して表示するための完全なコードです

public function add_kefu()	{	    if(isset($_POST['id']))	    {                $data['company_id']=$_POST['id'];                $data['kefu_name']=$_POST['kefu_name'];                $data['passwd']=$_POST['passwd'];                $data['kefu_type']=$_POST['kefu_type'];                $data['kefu_name']=$_POST['kefu_name'];                $data['open_time']=time();                if($data['kefu_type']=='robot')                    $data['is_online']=1;                $id=$this->table('kefu')->insert($data);                if($id)                {                    logs('(sql:):'.$this->getLastSql());                    alert('增加客服成功：其ID为:'.$id);                }else                {                    alert('增加客户失败：原因为:'.$this->getLastError());                }	    }else	    {	       $this->company_id=isset($_GET['id'])?$_GET['id']:0;	       $this->display();	    }	}

2 番目の実際のコード:

//查看本公司所有客服列表	public function view_kefu()	{	    $company_id=$_GET['id'];	    $list=$this->table('kefu')->where('company_id',$company_id)->select();	    if(is_array($list))	    formatDate($list, 'open_time,last_heartbeat');	    $this->assign('list',$list);	    $this->display();	}

これは 2 番目の実際のコードです。ご覧のとおり、これらはすべて非常に単純なコードです。

ポスターにはすでにそのようなフレームワークがあるので、それを共有して、みんなが学ぶことができるようにしましょう。

私も社内で実​​践しているのですが、書いてからまだ一ヶ月も経っていません。

データベース以外のビジネス ロジック操作の場合、この MODEL はどこに配置する必要があるか?

モデルとは関係ありません。
実際、私はすでにこの質問に上記で回答しており、クラス ライブラリ呼び出しにしています。

MVC中M的主要是处理数据库或者业务逻辑。
更简单的说，其实把C看成商人，V看成顾客，而M则看成生产商。当生产商（M）取消后，那么意味着商人（C）就要承担生产商（M）的责任。虽然看似省略了一步，但其实只是内部消化而已，没了M，那么必然会有另一种产物来替代，来解决所有只在C中处理的业务。当然，也可以都用C，不用M或另一种替代M的方案，这也会使C的负担增大，代码也会更加复杂，代码重用性也会相对降低等等。Thinkphp中封装的一些数据库操作的方法，但未必就不是M的代替口。

个人观点，不喜勿喷~~~

你这是过去的理论，没错，现在编程语言进化，比如php。省略model层。根本没有增加C的负担，反而减小了。这是实际编程出来的结果。

下面代码就是Controler中增加和显示客服的完整代码

public function add_kefu()	{	    if(isset($_POST['id']))	    {                $data['company_id']=$_POST['id'];                $data['kefu_name']=$_POST['kefu_name'];                $data['passwd']=$_POST['passwd'];                $data['kefu_type']=$_POST['kefu_type'];                $data['kefu_name']=$_POST['kefu_name'];                $data['open_time']=time();                if($data['kefu_type']=='robot')                    $data['is_online']=1;                $id=$this->table('kefu')->insert($data);                if($id)                {                    logs('(sql:):'.$this->getLastSql());                    alert('增加客服成功：其ID为:'.$id);                }else                {                    alert('增加客户失败：原因为:'.$this->getLastError());                }	    }else	    {	       $this->company_id=isset($_GET['id'])?$_GET['id']:0;	       $this->display();	    }	}

实际代码之二：

//查看本公司所有客服列表	public function view_kefu()	{	    $company_id=$_GET['id'];	    $list=$this->table('kefu')->where('company_id',$company_id)->select();	    if(is_array($list))	    formatDate($list, 'open_time,last_heartbeat');	    $this->assign('list',$list);	    $this->display();	}

这是真实代码之二。可以看出，都是非常简单的代码。

这些代码确实简单，同时业务也不复杂~~
复杂的业务或需要复杂的sql，又该如何呢？
诚然，你上面的代码干净、利落，但是Think中用的M()，你这里用的this，或许是在C中封装的，但未必不是M的衍生物来代替Model的，复杂的东西依旧需要放到类库里或其他封装类里，也依旧是需要引用的

虽然观点不一致，但还是很佩服楼主的，有自己的想法和坚持~

楼主的那两段代码实际都是业务逻辑，属于M的范畴
作为实际的项目，当然可以这样写
但如果是继承于 model 的话，也就 D('add_kefu')、D('view_kefu') 这样就可以了
框架与实际项目的区别在于框架总是要与未知的对象打交道，所以任何一个环节都不能写死
实际项目只关心具体的业务，但写死后对日后会差生一些影响

这个就是写在C里的M吧，我最初碰到前台会员和后台管理员都需要编辑产品的时候也是这样做的（ThinkPHP）

\Admin\Controller\ProductController.class.php：

namespace Admin\Controller;use Api\Controller\ProductController as ApiProduct;class ProductController extends AdminController {    public function edit() {        if (I('submit')) {            $res = ApiProduct::setInfo(I());            if ($res === true) {                $alert = I('id') ? '编辑成功' : '发布成功';                $this->success($alert, '/admin/product');                exit;            } else {                $this->error($res);            }        }        I('id') && $this->data = ApiProduct::getInfo(I('id'));        $this->cate = ApiProduct::getCate();        $this->paramdata = ApiProduct::getParam();        $this->param = C('YH_PARAM');        $this->title = I('id') ? '商品编辑' : '商品发布';        $this->display('product/edit');    }}

\Api\Controller\ProductController.class.php：

    public function getInfo($id) {        $id = intval($id);        $data = M('product')->where("id = $id")->find();        $stripfield = array('name', 'name_en', 'content', 'content_en');        foreach ($stripfield as $field) {            $data[$field] = stripslashes($data[$field]);        }        $data['adddate'] = date('Y-m-d', $data['addtime']);        $data['pathArr'] = explode('-', $data['path']);        $data['img'] = ImageController::getAll(1, $id);        return $data;    }    public function setInfo($post) {        $id = intval($post['id']);        $data = array();        $data['logo'] = $post['logo'];        $data['name'] = $post['name'];        $data['name_en'] = $post['name_en'];        $cid = intval($post['cid']);        $data['path'] = self::getCatePath($cid);        list($top) = explode('-', $data['path']);        $param = C('YH_PARAM');        foreach ($param as $key => $val) {            $data[$val['field']] = $post[$val['field']][$top];        }        $data['content'] = $post['content'];        $data['content_en'] = $post['content_en'];        $data['urltb'] = format_url($post['urltb']);        $data['urlone'] = format_url($post['urlone']);        $data['urljd'] = format_url($post['urljd']);        if (empty($data['name']) || empty($data['name_en'])) {            return '商品名称不能为空';        }        if (empty($data['path'])) {            return '请选择分类';        }        if ($id) {            $data['id'] = $id;            M('product')->save($data);        } else {            $data['addtime'] = time();            $id = M('product')->add($data);        }        ImageController::addImg($post['newimg'], 1, $id);        ImageController::delImg($post['delimg']);        if (empty($data['logo'])) {            $logo = ImageController::getOne(1, $id);            M('product')->where("id = $id")->setField('logo', $logo);        }        return true;    }

我把这些通用接口都写在C里面了，但觉得实际上就是M...
比如登陆操作，有个login接口，若干个参数。传入用户名密码然后返回true或是失败原因。这个过程中要写session或是向session服务器提交。是否需要记住密码自动登陆？这个参数会影响到写cookie。是否把登陆id记录到共享内存中实现一些其他功能？我觉得这些操作都算在用户登陆的M里

是的，那些就是 M，虽然写在 C 里但依然是 M
C的作用其实就是分析用户的需求，把需求发往 M，接受 M 的返回并发往 V
C 的工作是隐蔽的，不受干涉的

MVC中M的主要是处理数据库或者业务逻辑。
更简单的说，其实把C看成商人，V看成顾客，而M则看成生产商。当生产商（M）取消后，那么意味着商人（C）就要承担生产商（M）的责任。虽然看似省略了一步，但其实只是内部消化而已，没了M，那么必然会有另一种产物来替代，来解决所有只在C中处理的业务。当然，也可以都用C，不用M或另一种替代M的方案，这也会使C的负担增大，代码也会更加复杂，代码重用性也会相对降低等等。Thinkphp中封装的一些数据库操作的方法，但未必就不是M的代替口。

个人观点，不喜勿喷~~~

你这是过去的理论，没错，现在编程语言进化，比如php。省略model层。根本没有增加C的负担，反而减小了。这是实际编程出来的结果。

下面代码就是Controler中增加和显示客服的完整代码

public function add_kefu()	{	    if(isset($_POST['id']))	    {                $data['company_id']=$_POST['id'];                $data['kefu_name']=$_POST['kefu_name'];                $data['passwd']=$_POST['passwd'];                $data['kefu_type']=$_POST['kefu_type'];                $data['kefu_name']=$_POST['kefu_name'];                $data['open_time']=time();                if($data['kefu_type']=='robot')                    $data['is_online']=1;                $id=$this->table('kefu')->insert($data);                if($id)                {                    logs('(sql:):'.$this->getLastSql());                    alert('增加客服成功：其ID为:'.$id);                }else                {                    alert('增加客户失败：原因为:'.$this->getLastError());                }	    }else	    {	       $this->company_id=isset($_GET['id'])?$_GET['id']:0;	       $this->display();	    }	}

实际代码之二：

//查看本公司所有客服列表	public function view_kefu()	{	    $company_id=$_GET['id'];	    $list=$this->table('kefu')->where('company_id',$company_id)->select();	    if(is_array($list))	    formatDate($list, 'open_time,last_heartbeat');	    $this->assign('list',$list);	    $this->display();	}

这是真实代码之二。可以看出，都是非常简单的代码。

这些代码确实简单，同时业务也不复杂~~
复杂的业务或需要复杂的sql，又该如何呢？
诚然，你上面的代码干净、利落，但是Think中用的M()，你这里用的this，或许是在C中封装的，但未必不是M的衍生物来代替Model的，复杂的东西依旧需要放到类库里或其他封装类里，也依旧是需要引用的

虽然观点不一致，但还是很佩服楼主的，有自己的想法和坚持~

复杂的东西，当然需要另外有类。肯定的。

这个就是写在C里的M吧，我最初碰到前台会员和后台管理员都需要编辑产品的时候也是这样做的（ThinkPHP）

\Admin\Controller\ProductController.class.php：

namespace Admin\Controller;use Api\Controller\ProductController as ApiProduct;class ProductController extends AdminController {    public function edit() {        if (I('submit')) {            $res = ApiProduct::setInfo(I());            if ($res === true) {                $alert = I('id') ? '编辑成功' : '发布成功';                $this->success($alert, '/admin/product');                exit;            } else {                $this->error($res);            }        }        I('id') && $this->data = ApiProduct::getInfo(I('id'));        $this->cate = ApiProduct::getCate();        $this->paramdata = ApiProduct::getParam();        $this->param = C('YH_PARAM');        $this->title = I('id') ? '商品编辑' : '商品发布';        $this->display('product/edit');    }}

\Api\Controller\ProductController.class.php：

    public function getInfo($id) {        $id = intval($id);        $data = M('product')->where("id = $id")->find();        $stripfield = array('name', 'name_en', 'content', 'content_en');        foreach ($stripfield as $field) {            $data[$field] = stripslashes($data[$field]);        }        $data['adddate'] = date('Y-m-d', $data['addtime']);        $data['pathArr'] = explode('-', $data['path']);        $data['img'] = ImageController::getAll(1, $id);        return $data;    }    public function setInfo($post) {        $id = intval($post['id']);        $data = array();        $data['logo'] = $post['logo'];        $data['name'] = $post['name'];        $data['name_en'] = $post['name_en'];        $cid = intval($post['cid']);        $data['path'] = self::getCatePath($cid);        list($top) = explode('-', $data['path']);        $param = C('YH_PARAM');        foreach ($param as $key => $val) {            $data[$val['field']] = $post[$val['field']][$top];        }        $data['content'] = $post['content'];        $data['content_en'] = $post['content_en'];        $data['urltb'] = format_url($post['urltb']);        $data['urlone'] = format_url($post['urlone']);        $data['urljd'] = format_url($post['urljd']);        if (empty($data['name']) || empty($data['name_en'])) {            return '商品名称不能为空';        }        if (empty($data['path'])) {            return '请选择分类';        }        if ($id) {            $data['id'] = $id;            M('product')->save($data);        } else {            $data['addtime'] = time();            $id = M('product')->add($data);        }        ImageController::addImg($post['newimg'], 1, $id);        ImageController::delImg($post['delimg']);        if (empty($data['logo'])) {            $logo = ImageController::getOne(1, $id);            M('product')->where("id = $id")->setField('logo', $logo);        }        return true;    }

我把这些通用接口都写在C里面了，但觉得实际上就是M...
比如登陆操作，有个login接口，若干个参数。传入用户名密码然后返回true或是失败原因。这个过程中要写session或是向session服务器提交。是否需要记住密码自动登陆？这个参数会影响到写cookie。是否把登陆id记录到共享内存中实现一些其他功能？我觉得这些操作都算在用户登陆的M里

是的，你实际编程也是在和我一样。
我写的框架，从底层就支持这些了。
你的结果和我一样。

楼主的那两段代码实际都是业务逻辑，属于M的范畴
作为实际的项目，当然可以这样写
但如果是继承于 model 的话，也就 D('add_kefu')、D('view_kefu') 这样就可以了
框架与实际项目的区别在于框架总是要与未知的对象打交道，所以任何一个环节都不能写死
实际项目只关心具体的业务，但写死后对日后会差生一些影响

是的，那些就是 M，虽然写在 C 里但依然是 M
C的作用其实就是分析用户的需求，把需求发往 M，接受 M 的返回并发往 V
C 的工作是隐蔽的，不受干涉的

我认为：C处理业务逻辑。M处理数据相关。

你一定要这么认为，我也没办法
但是业务和数据是分不开的，不同的业务处理不同的数据。
这一点你不会否认吧？

你一定要这么认为，我也没办法
但是业务和数据是分不开的，不同的业务处理不同的数据。
这一点你不会否认吧？

MVC各如何处理，本就没有标准。老徐，你这么高手，天天混论坛，不无聊么？出来开发开发程序啊。
我认为业务和数据是可以分开的。C处理业务，M处理数据。真正复杂的处理数据时，可以另创建类。

那你干脆打混战，还讨论什么架构干什么？
快 70 了精力有限，偶尔接个小项目做做。泡论坛是为了不落伍，不动动脑筋不就痴呆了？

Laravel的作者写了一本书叫《From Apprentice To Artisan》，里面有个章节叫、。好像楼主已经到了跟大神同样的境界了。楼主可以去看看这本书。。。

具体没看懂，作者开发的框架里面有非常明确的MVC文件夹。但是写的书却推翻的了这个观点。楼主有兴趣研究那个吧。thinkphp已经不属于你研究的范畴了。

Laravel的作者写了一本书叫《From Apprentice To Artisan》，里面有个章节叫、。好像楼主已经到了跟大神同样的境界了。楼主可以去看看这本书。。。

具体没看懂，作者开发的框架里面有非常明确的MVC文件夹。但是写的书却推翻的了这个观点。楼主有兴趣研究那个吧。thinkphp已经不属于你研究的范畴了。

Baidu で Laravel コードを確認しました。モデルコードは私とほぼ同じです。しかし、私のコードは彼のコードよりもアーティストです。よりシンプルに、より美しく。
このようなフレームワークを実装するには、もちろんモデルは必要ありません。私と同じ考えです。
本当にバイバイです。
phpレベルの観点から。 ThinkPhP の作者はすでに非常に高いレベルにあります。彼は PHP 開発において 10 年以上の経験があります。

Laravel はもはや MVC の範疇ではありません (実際、さまざまなアーキテクチャやデザインパターンの間に明確な境界線はありません)
彼は MVC に従っていくつかの特徴についても説明しましたが
3 層と言いたい場合は、境界はそれほど明確ではないようです。データベースにはビューでアクセスできますが、これは 3 つのレイヤーでは決して許可されません
このルーティングは、実際には REST モードの典型的なアプリケーションです。
PEST はステートレスであるため、ユーザー認証を必要とするアプリケーション システムには明らかに適していません
したがって、Laravel はいくつかの慣例を破る必要があります

要するに、Laravel は依然として寄せ集めであり、実際、他のフレームワークも寄せ集めです

フレームワークは完全に良くはない 悪いと悪いの唯一の違いは、それが適切かどうかです。 。
投稿者の小さな改革には、おそらく複雑なビジネスは含まれていませんでした。 。
ここでは、M と C の間にモジュールを追加します。C はさまざまなモジュールを直列に接続するだけで、モジュールはそれを実現するためにモデルを操作します。 。各業務モジュールの結合度が非常に低く、非常に使いやすいと感じます。 。

良いフレームワークと悪いフレームワークの間には完全な区別はなく、単にそれらが適切かどうかだけです。 。
投稿者の小さな改革には、おそらく複雑なビジネスは含まれていませんでした。 。
ここでは、M と C の間にモジュールを追加します。C はモジュールを直列に接続するだけで、モジュールはそれを実現するためにモデルを操作します。 。各業務モジュールの結合度が非常に低く、非常に使いやすいと感じます。 。

敬意を表しますが、あなたの最初の文は正しいように見えますが、実際には完全に間違っています。
正しいことも間違っていることもありませんか？ただスタンスが違うだけ？なぜ刑務所が欲しいのですか？
敬意を表します、兄弟、あなたの判断力は非常に悪いです！

元の投稿者のアイデアに従って、私はこのフレームワークを完全に実装し、モデル層を完全にアクティブ化しました。これまでに 2 つのプロジェクトで使用されており、この思想的枠組みに基づいてコードを自動生成するシステムが構築されています。完璧かつ美しく実現しました。
まだ何も悪いところはありません。目的は達成されました。
結び目を作る準備をしましょう！

良いフレームワークと悪いフレームワークの間には完全な区別はなく、単にそれらが適切かどうかだけです。 。
投稿者の小さな改革には、おそらく複雑なビジネスは含まれていませんでした。 。
ここでは、M と C の間にモジュールを追加します。C はモジュールを直列に接続するだけで、モジュールはそれを実現するためにモデルを操作します。 。各業務モジュールの結合度が非常に低く、非常に使いやすいと感じます。 。

良いフレームワークと悪いフレームワークの間には完全な区別はなく、単にそれらが適切かどうかだけです。 。この文については特別な記事を用意しています。
モジュールは C&&V より上にある必要があります。私のフレームワークではモジュールの下にこれらしかありません。モジュールは単なるアイデアです。非プログラム。フレームワーク、アーキテクチャによって実装されます。

今日は単語を学びました: ナルシシズム

今日は単語を学びました: ナルシシズム

私も今日単語を学びました: wuzhi&&youzhi今日も単語を学びました: wuzhi&&youzhi

また会えて嬉しいです、元フォーチュン 500 PM!

今日は単語を学びました: wuzhi&& youzhi

P. S.、あなたのピンインと英語マッシュアップはとてもクールです! ちょっと待って、私が書いたものをコピーして貼り付けてからピンインを追加したのですか?今日: ナルシシズム

今日は wuzhi&&youzhi という言葉も学びました

追伸、ピンインと英語のマッシュアップはとてもクールです! ちょっと待って、私が書いたものをコピー＆ペーストして、ピンインを追加しただけですか？ それは、いけてないねえ。 以前のフォーチュン 500 PM としては最悪です!!!

最悪だ、P のような人たち

今日は単語を学びました: ナルシシズム

今日も単語を学びました: wuzhi& &youzhi。

追伸、ピンインと英語のマッシュアップはとてもクールです! ちょっと待って、私が書いたものをコピー＆ペーストして、ピンインを追加しただけですか？ それは、いけてないねえ。 以前のフォーチュン 500 PM としては最悪です!!!

最悪だ、P

いいね、元フォーチュン 500 PM のような人。 あなたが正しいです。 あなたの英語は最悪です
$data['company_id']=$_POST['id'];

$data['kefu_name']=$_POST['kefu_name'];
$data['passwd']=$_POST['passwd'];
$data['kefu_type']=$_POST['kefu_type'];
$data['kefu_name']=$_POST['kefu_name'];
$data['open_time']=time();

这种已经很复杂了啊、许必说これは代コード生成器生成のもの、ただし修正データテーブル構造の変更、これは一字段一字段の写し、これだけですHTML展示页面も要一冊?

$data['company_id']=$_POST['id'];

$data['kefu_name']=$_POST['kefu_name'];
$data['passwd']=$_POST['passwd'];
$data['kefu_type']=$_POST['kefu_type'];
$data['kefu_name']=$_POST['kefu_name'];
$data['open_time']=time();

这种已经很复杂了啊、许必说これは代コード生成器生成のもの、ただし修正データテーブル構造の変更、これは一字段一字段の写し、これだけですHTML展示页面も要一冊?

全てがマシンの生成、フロント台後台です。

この考えに基づくフレームワークは既に公開されています。

公開済みのバージョン: http://250.sz400.net/yuyan_kaifa.rar细説明文档（100%完整していません!）。

1、今回の公開は公開バージョンのためのみ提供されます 安全等忽略）
2、関連文書は doc 目录にあります
3、データファイルファイルはデータ目录にあります
4、配置
5、AppUser と System 100% コンピューター生成。非手動。
6、AppDefault 部分も生成され、人為的な変更はありません (1 時間程度)。

実行手順:
先の実行: YuYan.sql
再実行: data.sql
再修正: Appconfig 里データ パッケージ構成

この項目を再実行

登录用户名:13510668888 111111

配信期間が短いため、危険な発言は避けられますが、各位の承認は正しいです。