0

進化する基本アプリケーションがあります。現在、UIにはBLLが含まれています。DALは、その目的を果たす別個のライブラリです。

今はすべてを行う時間がないので、デカップリングに役立つパターンをバイパスしたいと思います（IoC、DI、ここで提案されています）。

BLLを作成し、DALのリファレンスを直接取得したいと思います。これにより、今必要な個別のUIの作成を開始する機会が得られます。

私の質問は私がそれをすることができますか？今すぐ3つのレイヤーの作成に集中し、コードを改善するためにデザインパターンを徐々に適用できますか？

追加情報：

最初のアプリは2番目のアプリの開発中に使用されないため、時間の余裕があります。だから私は私のコーディング構造を最適化する時間があります。UIをできるだけ効果的にUI+BLLに分割するために私が知ることができる質問。私の考えでは、BLLでDAL initを移動し、UIにBLLinitを配置します。後でIoC/DIを適用するときに、もっと役立つことができる他の何かがありますか？

4

3 に答える 3

2

動作する製品を迅速に入手することが最も重要な場合が多いため、一部のエンジニアリング手法をスキップするという意識的な決定を下すことが正しい場合があります。

ただし、適切なトレードオフを行っていることを確認する必要があります。リファクタリングは無料ではなく、技術的負債への対処を計画する必要があります。

エンドユーザーが最初のバージョンを確認した後の抵抗を最小限に抑える方法は、通常、最初の設計上の決定を再検討するよりも機能を追加し続けることです。

別の言い方をすれば、バージョン1.0が実際に使用されるようになると、目に見える変化や顧客への利益をもたらさないために、内部で物事をやり直すために多くの人日を費やす必要があるという経営陣を説得するのは難しいでしょう。

アプリの詳細や要件を知らなければ、具体的なアドバイスをすることはできません。一般に、設計について前もって考えることは、開発に同じことをしようとするよりも桁違いに速くて簡単です。

于 2012-12-12T09:13:25.787 に答える
1

この場合、私は「負債」の比喩がとても好きです。最初に機能するバージョンを提供し、コードの品質とエンジニアリングのベストプラクティスに妥協するのが早ければ早いほど、新しい変更要求を実装するのに時間がかかり、困難になります。

あなたがどれだけの「借金」を手に入れたいかを決めるのはあなた次第です。製品をゼロから作成することは、品質を示すユニークな機会だと考えてください。たとえば、1か月で納品するが、いくつかの簡単な変更要求を実装するのに5か月かかる場合、信頼性と評判が低下し、それらがあなたに取って代わります。

于 2012-12-12T10:02:07.907 に答える
1

この種の構造を使用して、「貧乏人の依存性注入」を設定できます。

public class MyEndClass
{
    private readonly IDependency dependency;

    public MyEndClass(IDependency dependency)
    {
        this.dependency = dependency;
    }

    // temporary constructor until we introduce IoC
    public MyEndClass() : this(new Dependency())
    {
    }
}
于 2012-12-12T10:24:28.917 に答える