6

現在、MVCでNopCommerceの最新バージョン（2.60）を検討しており、まもなく統合する予定です…ソースコードをダウンロードし、ユーザーガイドのドキュメントに20ドルを支払いました。ドキュメントは素晴らしいです！つまり…UIのフロントエンドとバックエンドをデプロイ、インストール、および回避する方法を説明しているという意味で素晴らしいです。これは全体的な概要としては素晴らしいことですが、欠けているのは、チームとしてNopCommerceを操作する方法を理解していることです。ベストプラクティスなどは何ですか/何ですか...

例として（または並行して）、Dotnetnukeをチームとして使用することにした場合、通常は次の方法で作業します。

  • 各開発者は、Dotnetnukeを自分のマシンにローカルにダウンロード/インストールします。
  • また、専用サーバー（たとえば、dev-server）にDotnetnukeをダウンロード/インストールします。
  • 開発者は、Dotnetnukeインストール内でローカルにテストするモジュールを作成および作成します。
  • 完了したら、モジュール（およびモジュールに付属するSQLスクリプト）をzipファイルにパッケージ化します。
  • パッケージの準備ができたら、そのパッケージを専用サーバー（dev-server）にアップロード/インストールします。

このアプローチは、Dotnetnukeに最適です。さらに重要なのは、モジュールを作成する開発者のチームがある場合です。

私の質問は、チームがNopCommerceMVCとどのように連携するかということです。

チームがコア要素/ソースを変更して、新しいバージョンへのアップグレードを不可能にする（または変更を壊す）場合に備えて、ソースコード内で直接作業することは悪い考えだと思います。

Dotnetnukeとの類似点が正しいかどうかはわかりませんが、チームがNopCommerce MVCとどのように連携するかについて、誰かが何か考えを持っている（または明確にするのを手伝ってくれる）でしょうか。

さらに、チームはNopCommerceのプラグインの作成のみに依存し、コアの変更を避けるべきですか、それともこれは無関係である必要がありますか？

最終的なNopCommerceMVCアップグレードで同様のオブジェクトが作成されたり、オブジェクトが上書きされたりした場合に備えて、SQLに新しいオブジェクトを追加する（または既存のオブジェクトを変更する）のはどうですか？

これに光を当てるのを手伝ってくれてありがとう。

心から

ヴィンス

4

1 に答える 1

6

NopCommerceのプラグインは、DNNのモジュールとほとんど同じです。何をする必要があるかによっては、コアコードを変更する必要がある場合があります。

私がサービスに対して行ってきたことは、新しいクラスを作成し、既存のサービスから継承してから、変更する関数をオーバーライドすることです。新しいDependencyRegistrarクラスを作成し、その特定のインターフェイスの実装として新しいサービスクラスを設定します。また、DRクラスがストッククラスの後にロードされるように、Orderプロパティが1であることを確認してください。コアクラスから継承しているため、オーバーライドしなかった関数はすべて親クラスによって処理されます。新しい関数を追加する必要がある場合は、インターフェイスを変更し、stockクラスにスタブを配置して、自分で実装するだけです。

Nop.Webプロジェクトのビューは、テーマで上書きできます。管理者のものとWebコントローラーはより巧妙になります。これらのファイルを直接変更しているだけです。

CoreクラスとDataクラスは、部分クラスを使用して新しいフィールドを追加することで実行できます。

いずれの場合も、更新がリリースされたときに、変更をソリューションとマージする必要があります。私の意見では、今すぐクリーンで読みやすいコードを記述し、マージの弾丸が来たら噛むほうがよいと思います。

私は単一の開発者なので、SQLスクリプトについては今のところあまり心配していませんが、ALTERスクリプト用のフォルダーを追加して、作成された日の名前を付けてください。次に、各開発者は、最新の状態になったときに実行する必要のあるスクリプトを認識します。

于 2012-08-09T14:40:45.913 に答える