2

私のC＃/ ASP.NETプロジェクトには、特定のカテゴリの動作を持つオブジェクトがあります。各動作カテゴリは物理的にルートオブジェクトに依存していますが、コードを読みやすくするために、カテゴリを明確に区別したいと思います。私の実装が、同じ問題を解決するために他の人が書いたものとどのように比較されるかを見るのは興味深いと思います。

以下の例では、Webサイトのさまざまな場所へのURLを生成するクラスがあります。Webサイトには、ホームページなどのURLとは異なる方法でアクセスする必要がある独自のリンクセットを持つストアフロントがあります。

public class WebsiteURLs
{
   // One category of urls on the website is the store.
   public class StoreURLs
   {
     private WebsiteURLs _website;
     public class StoreURLs(WebsiteURLs website)
     {
       _website = website;
     }
     public string BestSellers
     { 
        get { return _website.ResolveURL("~/store/bestSellers.html"); }
     }
   }
   private StoreURLs _store;
   public StoreURLs Store // property for generating store urls
   {
     get
     {
        if (_store == null ) {
          _store = new StoreURLs(this);
        }
        return _store;
     }
   }

   public string Homepage
   {
       get { return ResolveURL("~/default.aspx"); }
   }

   // .. Other Categories Here
   protected string ResolveURL(string url)
   {
     return HttpContext.Current.Response.ApplyAppPathModifier(url);
   }
}

このコードを使用すると、次のようになります

WebsiteURLs website;
Console.WriteLine(website.Store.BestSellers);

ロバート：

例自体は、機能をより明示的に整理しようとしていることに気付いた1つのシナリオにすぎません。関連するメソッドの前後にプレフィックスを使用していることに気付いたことがありますか。String.TrimStart（）、String.TrimEnd（）、String.Trim（）は、C＃フレームワークから思い浮かぶ例です。

上記のコードを（読みやすさの観点から）整理しようとすると、ネストされたクラスが外部クラスのメンバーにアクセスできないという問題があります。WebサイトURLインスタンスの参照をStoreURLsクラスのコンストラクターに渡す必要があるため、内部クラスの構築に余分な作業が必要です。このクロージャの動作は、言語。関連する機能がたくさんある状況で他の人がどのC＃コードを使用するのか興味があります（数十または数百のメソッドを考えてください）。（注：上記のコードは、ネストされたクラスが外部クラスのメンバーにアクセスできるJavaで記述する方がはるかに流動的です）。

4

5 に答える 5

2

あなたの例を見たときの私の即時の反応は、比較的静的なもの (型のセット) を比較的動的なもの (Web サイトに属する一連の URL) にバインドしていると考えることです。それは私には間違ったにおいがします。これを行うと、コードが Web サイトの構造と機能に密接に結合されます。バインドしている Web サイト内の任意の URL を変更すると、ソフトウェアを再構築して再展開する必要があります。

ですので、やるならそれなりの理由が必要です。あなたはこれから何を得ていますか？Web ページの階層で型チェック (およびおそらく IntelliSense) を使用する機能。これを手に入れるために、あなたは本当に大きな代償を払っています。

その価値はありますか？これは：

url = website.Store.BestSellers;

これよりもはるかに優れています：

url = website.GetUrl("Store.BestSellers");

それを達成するためだけに費やさなければならない労力に見合うだけの価値があると思いますか?

その質問に対する答えが「はい」となる状況は確かにあります。しかし、私はそれを知っていることを確認せずに、このデザインにこれ​​以上時間を費やすことはありません.

于 2009-07-29T06:31:24.697 に答える
0

私はロバートに同意します。もう 1 つの方法は、サイト URL のリソース ファイル (キー/値) を作成し、次のように参照することです。

文字列 url = Resources.Navigation.Home;

実行時ではなくコンパイル時に名前の自動チェックを提供します（文字列はそれまで評価されないため）

于 2009-07-29T07:30:32.033 に答える
0

Use C# Regions. Regions will categories your code properly.

public class WebsiteURLs
{
   #region StoreURLs sub-class
   // One category of urls on the website is the store.
   public class StoreURLs
   {
     private WebsiteURLs _website;
     public class StoreURLs(WebsiteURLs website)
     {
       _website = website;
     }
     public string BestSellers
     { 
        get { return _website.ResolveURL("~/store/bestSellers.html"); }
     }
   }
   #endregion

   #region StoreURLs prop. accessor
   private StoreURLs _store;
   public StoreURLs Store // property for generating store urls
   {
     get
     {
        if (_store == null ) {
          _store = new StoreURLs(this);
        }
        return _store;
     }
   }
   #endregion

   #region Homepage
   public string Homepage
   {
       get { return ResolveURL("~/default.aspx"); }
   }
   #endregion

   #region Methods
   // .. Other Categories Here
   protected string ResolveURL(string url)
   {
     return HttpContext.Current.Response.ApplyAppPathModifier(url);
   }
   #endregion
}
于 2009-07-29T05:35:31.907 に答える
0

目標を理解しているかどうかはわかりません。しかし...

生成作業のほとんどを行うインターフェイスまたは基本クラスを作成し、そこからカテゴリごとに派生させるだけでよいと思います。

または、カテゴリ列挙に応答するファクトリ クラスを作成します。

于 2009-07-29T05:37:38.113 に答える
0

私はweb.config、リソースファイル、またはデータベースでパスを設定します。そうすることで、多くの利点が得られます。たとえば、テスト/本番用に異なる設定を使用でき、設定を変更せずに編集するだけで別のページに切り替えることができますソースと再コンパイル中...

于 2009-07-29T07:24:41.093 に答える