長い間、プログラミング MVC アーキテクチャは人々の心に深く根付いてきました。プログラミング言語の継続的な進歩と開発に伴い。このアーキテクチャは決して進歩していません。私たちは MVC モデルを VC モデルに大胆に進化させようとしています。 [注意してください] 私は進化を使用しています。これは、最初に MVC、次に VC を意味します。ダイレクトVCモードではなく。
繰り返しますが、これは MVC モデルが悪いと言っているわけではありません。実際には、さらに進化する可能性があります。 MVC パターンに慣れていないと、VC パターンを理解できません。
Model の明らかな省略は、プログラミング言語の進化の結果です。退化するというよりも。これにより効率が大幅に向上します。 。 。
1. モデルの前提条件を省略します。
2. モデルの実装を省略します。
3. モデルを省略することの強力な利点。
4. モデルの省略によって失われた機能をどのように補うか?
5. この VC アーキテクチャ用の PHP フレームワークの実装。
上記の機能は以下に徐々に追加されます...
ここで提案があります。アドバイスをいただければ幸いです。 。 。 。
フォローしていただきありがとうございます。 。 。 。
まずレンガを投げる: あなたは MV に退化しました
まずレンガを投げます: あなたは MV に退化しました
まずレンガを投げておきます。あなたは MV に退化しました
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 の代替にはならない場合があります。
個人的な意見、気に入らない場合は批判しないでください~~~
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(); }
ポスターにはすでにそのようなフレームワークがあるので、それを共有して、みんなが学ぶことができるようにしましょう。
データベース以外のビジネス ロジック操作の場合、この MODEL はどこに配置する必要があるか?
MVC中M的主要是处理数据库或者业务逻辑。
更简单的说，其实把C看成商人，V看成顾客，而M则看成生产商。当生产商（M）取消后，那么意味着商人（C）就要承担生产商（M）的责任。虽然看似省略了一步，但其实只是内部消化而已，没了M，那么必然会有另一种产物来替代，来解决所有只在C中处理的业务。当然，也可以都用C，不用M或另一种替代M的方案，这也会使C的负担增大，代码也会更加复杂，代码重用性也会相对降低等等。Thinkphp中封装的一些数据库操作的方法，但未必就不是M的代替口。
个人观点，不喜勿喷~~~
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(); } 楼主的那两段代码实际都是业务逻辑，属于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'); }} 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; } 是的，那些就是 M，虽然写在 C 里但依然是 M
C的作用其实就是分析用户的需求，把需求发往 M，接受 M 的返回并发往 V
C 的工作是隐蔽的，不受干涉的
MVC中M的主要是处理数据库或者业务逻辑。
更简单的说，其实把C看成商人，V看成顾客，而M则看成生产商。当生产商（M）取消后，那么意味着商人（C）就要承担生产商（M）的责任。虽然看似省略了一步，但其实只是内部消化而已，没了M，那么必然会有另一种产物来替代，来解决所有只在C中处理的业务。当然，也可以都用C，不用M或另一种替代M的方案，这也会使C的负担增大，代码也会更加复杂，代码重用性也会相对降低等等。Thinkphp中封装的一些数据库操作的方法，但未必就不是M的代替口。
个人观点，不喜勿喷~~~
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(); }
这个就是写在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'); }} 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; }
楼主的那两段代码实际都是业务逻辑，属于M的范畴
作为实际的项目，当然可以这样写
但如果是继承于 model 的话，也就 D('add_kefu')、D('view_kefu') 这样就可以了
框架与实际项目的区别在于框架总是要与未知的对象打交道，所以任何一个环节都不能写死
实际项目只关心具体的业务，但写死后对日后会差生一些影响
是的，那些就是 M，虽然写在 C 里但依然是 M
C的作用其实就是分析用户的需求，把需求发往 M，接受 M 的返回并发往 V
C 的工作是隐蔽的，不受干涉的
你一定要这么认为，我也没办法
但是业务和数据是分不开的，不同的业务处理不同的数据。
这一点你不会否认吧？
你一定要这么认为，我也没办法
但是业务和数据是分不开的，不同的业务处理不同的数据。
这一点你不会否认吧？
那你干脆打混战，还讨论什么架构干什么？
快 70 了精力有限，偶尔接个小项目做做。泡论坛是为了不落伍，不动动脑筋不就痴呆了？
Laravel的作者写了一本书叫《From Apprentice To Artisan》，里面有个章节叫
具体没看懂，作者开发的框架里面有非常明确的MVC文件夹。但是写的书却推翻的了这个观点。楼主有兴趣研究那个吧。thinkphp已经不属于你研究的范畴了。
Laravel的作者写了一本书叫《From Apprentice To Artisan》，里面有个章节叫
具体没看懂，作者开发的框架里面有非常明确的MVC文件夹。但是写的书却推翻的了这个观点。楼主有兴趣研究那个吧。thinkphp已经不属于你研究的范畴了。
Laravel はもはや MVC の範疇ではありません (実際、さまざまなアーキテクチャやデザインパターンの間に明確な境界線はありません)
彼は MVC に従っていくつかの特徴についても説明しましたが
3 層と言いたい場合は、境界はそれほど明確ではないようです。データベースにはビューでアクセスできますが、これは 3 つのレイヤーでは決して許可されません
このルーティングは、実際には REST モードの典型的なアプリケーションです。
PEST はステートレスであるため、ユーザー認証を必要とするアプリケーション システムには明らかに適していません
したがって、Laravel はいくつかの慣例を破る必要があります
要するに、Laravel は依然として寄せ集めであり、実際、他のフレームワークも寄せ集めです
フレームワークは完全に良くはない 悪いと悪いの唯一の違いは、それが適切かどうかです。 。
投稿者の小さな改革には、おそらく複雑なビジネスは含まれていませんでした。 。
ここでは、M と C の間にモジュールを追加します。C はさまざまなモジュールを直列に接続するだけで、モジュールはそれを実現するためにモデルを操作します。 。各業務モジュールの結合度が非常に低く、非常に使いやすいと感じます。 。
良いフレームワークと悪いフレームワークの間には完全な区別はなく、単にそれらが適切かどうかだけです。 。
投稿者の小さな改革には、おそらく複雑なビジネスは含まれていませんでした。 。
ここでは、M と C の間にモジュールを追加します。C はモジュールを直列に接続するだけで、モジュールはそれを実現するためにモデルを操作します。 。各業務モジュールの結合度が非常に低く、非常に使いやすいと感じます。 。
元の投稿者のアイデアに従って、私はこのフレームワークを完全に実装し、モデル層を完全にアクティブ化しました。これまでに 2 つのプロジェクトで使用されており、この思想的枠組みに基づいてコードを自動生成するシステムが構築されています。完璧かつ美しく実現しました。
まだ何も悪いところはありません。目的は達成されました。
結び目を作る準備をしましょう！
良いフレームワークと悪いフレームワークの間には完全な区別はなく、単にそれらが適切かどうかだけです。 。
投稿者の小さな改革には、おそらく複雑なビジネスは含まれていませんでした。 。
ここでは、M と C の間にモジュールを追加します。C はモジュールを直列に接続するだけで、モジュールはそれを実現するためにモデルを操作します。 。各業務モジュールの結合度が非常に低く、非常に使いやすいと感じます。 。
今日は単語を学びました: ナルシシズム
今日は単語を学びました: ナルシシズム
また会えて嬉しいです、元フォーチュン 500 PM!
今日は wuzhi&&youzhi という言葉も学びました
追伸、ピンインと英語のマッシュアップはとてもクールです! ちょっと待って、私が書いたものをコピー＆ペーストして、ピンインを追加しただけですか？ それは、いけてないねえ。 以前のフォーチュン 500 PM としては最悪です!!!
今日は単語を学びました: ナルシシズム
$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
配信期間が短いため、危険な発言は避けられますが、各位の承認は正しいです。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
