0

サーバーコントロールによるこの長いIDがますます嫌いになっています...

しかし、コードビハインドでそれを生成する他の方法は、asp.netの簡単なことの意味ではないと思いますか?

それで、あなたはあなた自身でその方法を好みますか?来年は会社で中規模から大規模のプロジェクトを作成する予定です。それが私が尋ねる理由です。私自身はPHPから来ており、クリーンなソースコードで覚えている間、私は病気になるでしょう:)

私はasp.netWebフォームを使用していますが、実際には、クールなソリューションを短時間で簡単に開発できます。MVCのいくつかの印象の後、この方法でも可能かどうかはわかりません。

4

4 に答える 4

2

私はあなたとまったく同じ気持ちですが、私は醜いIDで生きることを選びます。

ただし、2つの良いオプションがあります。

  • ASP.NET MVC

  • そして、ASP.NET4.0を待ちます。ブラウザに何を出力するかを完全に制御できるオプションを設定できます。

于 2010-01-20T13:01:51.313 に答える
1

これは、ASP.NETWebフォームからASP.NETMVCに切り替える最大の理由の1つです。この問題を軽減するためにWebFormsでできることはあまりありませんが、ハッキングとは見なされません(そして、私は確かにこの理由で場所をハッキングしました)。

于 2010-01-20T13:03:22.183 に答える
1

通常、CodeBehindでコントロールを生成することは、視覚的なレイアウトが少し難しくなるため、望ましくありません。ただし、覚えておくべきことがいくつかあります。

まず、CodeBehindでコントロールを作成することは難しくありませんが、UIレイアウトだけにとどまらないコストがかかります。つまり、後でページに再度アクセスして、どこから何が発生するかを把握する必要がある場合に、コストが発生します。注意しないと、CodeBehindで何かを行うとつまずく可能性があります。

次に、ASP.NET 4.0にジャンプするのに十分な柔軟性を維持できる場合、4.0はクライアント側のIDを定義する方法を提供するため、フラストレーションは短命になります。

第三に、MVCは代替手段ですが、実際に始めたばかりでない限り、そのようにすることを躊躇します。WebForms開発に慣れている人々の生産性に関して、MVCには重大な欠点があります。これについては、ここで詳しく説明します。

現在、Javascript / JQueryからコントロールを参照する必要がある場合は、複雑なIDを処理する必要があります。これはほとんどの状況で比較的制限された問題であり、4.0に移行するとすぐに解消されます。ただし、MVCは大きなコミットメントです。考え方が異なり、WebForms開発に慣れている場合は、ツールベルトから非常に生産的なツールを削除します。それを採用する主な理由-簡単なJQuery統合などの他のツールの追加-も.NET4の変更によって弱められています。 結局、どちらが「最良」であるかについての決定ではなく、決定です。どちらがあなたの開発スタイルと感性に合っているかについて。

幸運を!

PS: .NET 4 / Visual Studio 2010を今すぐ入手できることをご存知ですか?展開可能なプロジェクトの準備が整っており、VS2008からの重要なステップアップを表しています。

于 2010-01-20T13:23:40.890 に答える
0

私はこれに出くわしました、そして私はそれがこれに関連しているかもしれないと思いました。

http://www.west-wind.com/WebLog/posts/4605.aspx

これは、UniqueIDとClientIDの両方をIDにオーバーライドします。これは、はるかにクリーンです。

public override string UniqueID
{
    get
    {
        return this.ID;
    }
}

public override string ClientID
{
    get
    {
        return this.ID;
    }
}
于 2010-03-18T12:33:31.933 に答える