近年、私はさまざまなバックエンドフレームワークとフロントエンドフレームワークを使用して、いくつかの大規模なプロジェクトに取り組むことができました。アプリケーションの成長に伴って発生したさまざまな問題に直面しました。これで、どのソリューションが成功し、どれがあまり成功しなかったかを結論付けることができます。私は蓄積された経験を使用して、私の意見ではすべての最高のソリューションを収集し、SPAの独自の基盤を作成することに着手しました。Laravelでサイトを作成する方法やSPAとは何か、私は教えません。インターネット上にそのような十分な情報があります。この記事は多かれ少なかれ経験豊富な開発者を対象としているので、いくつかの詳細を見逃してしまいます。記事の最後には、私のgithubレポジトリへのリンクがあります。LaravelとVue.js + Vuexがメインスタックであるため、メインテクノロジーが選択されました。
迅速な開発のために、UIキット-ElementUIを採用しました。主な目的
中規模および大規模プロジェクトの基盤を作成するには、次のようにします。- モジュールの固い結束を回避するのに役立ちます
- 経験の浅いプログラマーにも理解できる
- コードの重複を回避する
- 展開しやすい
- プロジェクトの開始時間を短縮する
- プロジェクトサポートとコードナビゲーションの時間を短縮する
プロジェクトで混乱しないように、人生をできるだけ簡単にするために、エゴを適切に構成する必要があります。最初に、アプリケーションは、ユーザーインターフェイス、データベース、ビジネスロジックなどの責任のレベルに分割する必要があります。さらに、各層は最初に機能ごとに分割し、次に各機能モジュールを選択したパターンに従って分割する必要があります。DDDの哲学に触発されて、私はフロントエンドとバックエンドをセマンティックモジュールに分割することにしました。しかし、これらはエヴァンスが説明する古典的なドメインではありません。彼のモデルも完璧ではありません。どのアプリケーションでも、時間の経過とともに、コンポーネント間の関係が常に表示されます。モデル間の関係は同じです。モデルはすべての接続を使用してデータベースを複製しているようだったため、モデルを別のレイヤーとして残しました。フロントにディレクトリを作成resources / js / modules。さまざまなモジュールが配置されます。それぞれにapi-バックエンド、コンポーネント -すべてのコンポーネントとページ、ストア -ストレージ、ルートを操作するためのメソッドがあります。{moduleName}/
│
├── routes.js
│
├── api/
│ └── index.js
│
├── components/
│ ├── {ModuleName}List.vue
│ ├── {ModuleName}View.vue
│ └── {ModuleName}Form.vue
│
└── store/
├── store.js
├── types.js
└── actions.js
リソース/ JS、コアフォルダが作成され、システムの主要な構成要素が配置されます。ブートストラップもあり、それぞれ追加のライブラリとユーティリティを構成するためのフォルダが含まれています。プロジェクトはモデルの動的ロードを使用します。つまり、コア/ルートおよびコア/状態では、対応するルーティングファイルとストレージファイルを自動的にロードします(何も登録する必要はありません)。以下は、異なるモジュールからstore.jsが自動的にロードされた例です。
const requireContext = require.context('../../modules', true, /store\.js$/)
let modules = requireContext.keys()
.map(file =>
[file.replace(/(^.\/)|(\.js$)/g, ''), requireContext(file)]
)
.reduce((modules, [path, module]) => {
let name = path.split('/')[0]
return { ...modules, [name]: module.store }
}, {})
modules = {...modules, core}
export default new Vuex.Store({
modules
})
appディレクトリのバックエンドには、同様のモジュールがあります。各モジュールには、フォルダーControllers、Requests、Resourcesが含まれます。ルートを含むファイルもここに移動されました-routes_api.php。{ModuleName}/
│
├── routes_api.php
│
├── Controllers/
│ └──{ModuleName}Controller.php
│
├── Requests/
│ └──{ModuleName}Request.php
│
└── Resources/
└── {ModuleName}Resource.php
イベント、ジョブ、ポリシーなどの他のデザインパターン使用頻度が低く、モジュールを別のレイヤーに保持する方が論理的であるため、モジュールには含まれません。モジュールの動的ロードを伴うすべての操作は、モジュール間の最小のエンゲージメントが打たれるように行われます。これにより、問題なくモジュールを追加および削除できます。これで、artisan makeコマンドを作成して、このようなモジュールを作成できます。その助けを借りて、プロジェクトをCRUD機能とともに必要なエンティティですばやく満たすことができます。コマンドを実行するphp artisan make:module {ModuleName}
と、完全なCRUDが機能するために必要なすべてのファイル(モデルや移行を含む)が揃います。移行を完了するだけですphp artisan migrate
そして、すべてが動作します。ほとんどの場合、追加のフィールドを追加する必要があるため、移行前に、それらをモデルに追加し、移行し、vueに出力することを忘れないでください。このテンプレートでは、認証にJWT-Authテクノロジーが使用されていましたが、冗長である可能性があり、Laravel Sanctum用に作り直す必要があります。次に、フロントエンドでvue-authが使用されるため、ユーザーの承認とロールの管理が容易になります。今後、システムを改善していきたいと思います。グローバルイベントバスを追加し、WebSocketを接続します。テストを追加します。別のブランチで役割管理オプションを作成するか、他のUIキットでブランチを作成することが可能です。推奨事項、コメントを聞いていただければ幸いです。このテンプレートは当初、お客様のニーズに合わせて開発されましたが、今は他のユーザーにも役立つことを願っています。すべてのコードは、私のgithubリポジトリで表示できます。