28

私はかなり大規模なアプリケーションと技術リーダーに取り組んでいますが、特定のことに目を向けていません。

それらの1つは、コンソールアプリケーションに関するものです。これらのアプリケーションは、シェルスクリプトからC＃に移植されています。これらのスクリプトの一部は適度に大きく（変換後のコードは300〜400行）、I / O、電子メール、データベースアクセスなどを実行します。

これらのスクリプトごとに、クラスを作成しました。各クラスには、その中にあるすべてのメソッド/操作を呼び出すRunメソッドがあります。Program.cs / main内で、上記のクラスのオブジェクトを作成し、Runを呼び出します。Program.csには、4〜5行のコードが含まれています。清潔でシンプル。

私の技術リーダーは、スクリプトクラスを取り除き、program.csのメインメソッド内にすべてを入れたいと考えています。彼の推論は、それがそうであるようにあまりにも混乱しているということです。

mainメソッドをいじる必要なしにクラスがクラスライブラリに再利用可能/パッケージ化可能でなくなるため、この方法でそれを行う必要があるのは厄介だと感じます。

Program.cs自体をインスタンス化できるため、単体テストは影響を受けていないように見えますが、これも不格好な感じがします。私が見ていない彼のやり方でそれをすることに何か利点はありますか？私のやり方で何かメリットはありますか？主な方法で大規模なアプリケーションやコンテンツを扱う場合の一般的な方法はありますか？

お時間をいただきありがとうございます。

4

8 に答える 8

35

mainメソッドをいじる必要なしにクラスがクラスライブラリに再利用可能/パッケージ化可能でなくなるため、この方法でそれを行う必要があるのは厄介だと感じます。

そのようにする必要はありません。

たとえば、各スクリプトは、それと同じ構造を持つことができますが、メソッドも持つことができます。private static void Main(string[] args)（必要に応じて非プライベートにすることもできます。すべてはニーズによって異なります。）

そうすれば、スタンドアロン（単一の入力として単一の出力にコンパイルして実行することができます）であり、便利な場合もありますが、クラスライブラリの一部として使用することもできます。結局のところ、Mainメソッドの存在は、クラスが他のクラスから使用されることを妨げるものではありません。

スクリプトごとに1つの Program.csファイルがあるのか​​1つあるのかは明確ではありません。スクリプトごとに1つあり、それぞれが4〜5行しかない場合、それはやや無意味に思えます。

これは確かに私が通常大規模なアプリケーションを構築する方法ではありませんが、それぞれがスタンドアロンで実行できる複数の「スクリプト」を用意することが重要な場合は、各クラスにメソッドを与えることMainはそれほど悪くはないようです。

実際、私がデモMainの目的でよく行うことは、単一のプロジェクトにメソッドを持つ複数のクラスがあり、次にリフレクションを使用して他のすべてを検索し、ユーザー/プレゼンターがどれを選択できるようにする別のエントリポイント（にある）を持ってProgram.csいることです実行するもの。

すべてのコードを1つのクラスに含めることが理にかなっている場合は、小さな追加のエントリメソッドを使用してもそれほど問題にはなりません。エントリポイントがどこにあるかに関係なく、実際には1つのクラスに対してコードが多すぎる場合は、別の問題です。（したがって、実際に異なるクラスに異なるタスクを与える必要があるときにシングルを使用することに固執した場合、それも悪いことです。）同様に、彼が本当にすべてのコードを単一のメソッドに含めることを主張している場合、それはテストと保守性。ScriptClass

現時点では、エントリポイントの不一致を脇に置いておくことをお勧めします。コードに関する他Mainのすべてを構造化するための最もクリーンな方法を考えてください。そうすれば、メソッドが別のクラスに入るのか、別のクラスに入るのかは実際には関係ありませんProgram.cs。

于 2012-10-15T22:09:08.163 に答える
4

コンソールアプリケーションのエントリポイントが構成可能であることをご存知ですか？

私の好みの方法は次のとおりです。

class MeaningfullyNamedProgram { 
    public static void Main(string[] args) {
        var program = new MeaningfullyNamedProgram(args);
        program.Run();
    }

    public MeaningfullyNamedProgram(string[] args) { 
    }

    public Run() {
        // well structured, broken-out code follows 
    }
}

プロジェクトのエントリポイントをMeaningfullyNamedProgram.Mainにポイントします

注：読者の演習として残しておきますが、ジェネリックスを使用してこのための基本クラスを作成し、入力を節約することができます。

于 2012-10-15T22:48:46.610 に答える
4

正直なところ、あなたは自分のために作品を作っていると思います。説明の詳細からはわかりませんが、シェルスクリプトが機能している場合、構造が明らかに不要な場所に構造化するのはなぜですか？

モジュール性と外部ライブラリへの再パッケージ化はあなたがしなければならないことだとあなたは言っています-私は「なぜ」と反論します。（これは私が余分な仕事によって意味するものです）。

単一のファイルに単純なメソッドのセットを作成する場合、それは単一のファイルです！定義上、複数のプロジェクトなどで作業する方が簡単です。

そうは言っても、詳細がない限り、私たちが何について話しているのかを知るのは難しいです。それが「毎晩レポートを送信し、これらの人々に電子メールを送信する」場合-ええ、それはクラスライブラリと大量のモジュール性を必要としないものです。メソッドを実行すると、完了です。

于 2012-10-15T22:23:44.037 に答える
3

あなたの技術リーダーは良い話をする必要があります！すべてをProgram.csに入れることは、前進する方法ではありません。

于 2012-10-15T22:08:37.220 に答える
3

まあ、彼のやり方は、サブルーチンが発明される前にプログラムがどのように書かれたかという点で、概念的に単純です...。

あなたのやり方はより良いです：それは再利用性をサポートし、修正とデバッグがより簡単になるでしょう。

私が彼のやり方で考えることができる他の唯一の正当化は、あなたが彼のやり方でそれをするよりもあなたがそれをあなたのやり方で行うのにかなり長い時間がかかった場合でした。しかし、それは彼の側の短期的な考え方の場合です。あなたのやり方は、時の試練に耐えることができます。

于 2012-10-15T22:10:41.937 に答える
2

あなたの技術リーダーは間違っています。提案する方法ははるかに合理的です。さまざまなスクリプトを簡単に統合できます。独自のMainメソッドを持つ各スクリプトは、特にこれらのいくつかを一度に実行できるアプリケーションを計画している場合は、扱いにくくなる可能性があります。

于 2012-10-15T22:11:11.070 に答える
1

ロジックを別のクラス（または複数のクラス）に分割するのが方法です。すべてを1つの場所にまとめると、SOLIDおよびDRY設計の原則に違反します。あなたは間違いなくあなたのアプローチで正しい軌道に乗っています。

クラスを単一の役割に集中させ続けるほど、メンテナンスとテストの生活が楽になります。

于 2012-10-15T22:10:39.693 に答える
1

コンソールプログラム以外の方法で機能を利用できる場合は、もちろん、適切にモデル化されたクラスライブラリにそれらを保持する必要があります。カプセル化された機能を使用してコマンドラインパラメータ処理をエンタンジェリングすることで数行のコードを節約することは、懸念が元々分離されていたという事実を考えると意味がありません。たぶん、あなたの技術リーダーはあなたのためにもっと生産的なタスクを見つけるはずです。

于 2012-10-15T22:13:33.143 に答える