5

MicrosoftWebアプリケーションアーキテクチャ関連...

新しいWebアプリケーションに.NetのMVCを使用しないことで間違いを犯しているのではないかと思いますか?私はASPClassicでWeb開発を開始し、ASP.netの反復ごとに前進してきました。私は過去数か月間ASP.netMVCをいじくり回してきましたが、その一部が気に入らなかっただけです。私はルーティング、かみそり、そして特定のモデルを表示するというアイデアが好きです。しかし、いくつかの機能を追加した後、私のアプリは非常に複雑になっているように見えました。nopCommerceやUmbracoなどのアプリのMVCバージョンを以前のバージョンと比較すると、同じことが当てはまると思います。

私は戻って、基本的に.NetWebサイト/MVCハイブリッドを書き始めました。データアノテーション検証を実装する「ビューモデル」用の独自の基本クラスを作成しました。フォーム送信をモデルにバインドし、エンティティプロパティをモデルプロパティに、またはその逆にマップするシンプルマッパー。ページング、チェック、選択、偶数/奇数などの拡張メソッドとヘルパーを作成しました。リピーター、リテラル、標準のHTMLタグなど、runat="server"ビューステートを必要としないコントロールを使用します。

このアプローチにより、両方の長所を活用でき、「コントローラー」コードを「ビュー」に近づけることができ、すべてが中程度の信頼で機能するようです。

サンプルコードは次のとおりです。

public partial class Admin_Users_RoleAdd : System.Web.UI.Page
{
    protected class RoleAddModel : BaseModel
    {
        [Required, StringLength(100)]
        public string Name { get; set; }
        [StringLength(250)]
        public string Description { get; set; }

        public override bool Validate()
        {
            if (base.Validate() && Cortex.DB.Roles.Any(r => r.Name == Name))
                Errors["Name"] = "Already in use";
            return Errors.Count == 0;
        }
    }
    protected RoleAddModel model = new RoleAddModel();
    protected override void OnInit(EventArgs e)
    {
        if (Request.Form["Submit"].HasValue())
        {
            SimpleMapper.FormMap<RoleAddModel>(model);
            if (model.Validate())
            {
                var entity = new Role();
                SimpleMapper.Map<RoleAddModel, Role>(model, entity);
                Cortex.DB.Roles.AddObject(entity);
                Cortex.DB.SaveChanges();
                Response.Redirect("Roles.aspx");
            }
        }
        base.OnInit(e);
    }
}

そして「ビュー」:

<h1>Add Role</h1>

    <div id="MainForm" class="form">
        <%= model.GetErrorMessage("Error") %>
        <form action="<%= Request.RawUrl %>" method="post">
            <div class="formField">
                <label for="Name">Name</label> <%= model.GetErrorMessage("Name") %><br />
                <input type="text" name="Name" value="<%: model.Name %>" class="required" maxlength="100" />                
            </div>
            <div class="formField">
                <label for="Description">Description</label> <%= model.GetErrorMessage("Description") %><br />
                <textarea rows="8" cols="40" name="Description" maxlength="250"><%: model.Description %></textarea>             
            </div>
            <div class="buttons">
                <input type="submit" name="Submit" value="Create" class="primary" />
                <a href="Roles.aspx">Back</a>
            </div>
        </form>
    </div>

このアプローチについて後で後悔することはありますか?現時点で私が考えることができる主なことはテスト能力ですが、VWDExpressはとにかくそれをサポートしていません。

4

5 に答える 5

2

私はMVCでのMicrosoftの実装が好きではありません。マジックストリングの使用、それはマイクロソリューション(ルーティング、かみそり)でいっぱいなので、それは十数の新しい言語を学ばなければならないようなものです。

とても嫌いなので自分で書き始めましたが、書くほど柔軟性がないことに気づき、修正すればするほど、Microsoftの実装に似たものになりました。

本質的にがらくたバージョンのMVCで何時間も何時間も開発した後、私はそれを捨てました。私は設計ドキュメントとコードに戻って、それらの上部に(または)上書きし始めました

少ないコードを書く

くだらないMVCアプリのUI層を約8時間でMSMVCに書き直しました。その前の約8週間はそれに取り組んでいました。考えのほとんどはすでに行われているので、MVCを最初から作成するのはそれほど迅速ではなかったかもしれません。

私が使用したほとんどすべては、AuthorizeAttributeクラスを除いて、箱から出してすぐに使用できました。AuthorizeAttributeクラスは、私が望んでいたことを実行しませんでした。

なぜこれがあなたの質問に関連するのですか?

必要のないときにコードを書くのは間違いです。ライブラリを試し、テストしたことがある場合は、ライブラリを再利用します。そうでない場合は、独自のライブラリを作成する前に、信頼できるソースからライブラリを探します。私の問題はどれも新しいものではなく、あなたの問題もそうであるかどうかは疑わしいものではありません。それらはすべて、私たちのほとんどよりも多くのリソースを自由に使える人々によって解決されてきました。

ホイールの再発明をやめ、パッケージ化されていないものをコーディングするだけでよいというこの認識の一部は、作業中の移行プロジェクトに取り組んでおり、弁護士がいくつかの暗号化ルーチンに関連するIPのより細かい点について話し合っています。データを保護するために使用されたIPを「譲渡」することはできないため、データを別の形式に変換するためのコードを作成するのに数週間を費やす必要があります。アプリが缶詰のライブラリで作成された場合、それはデータと暗号化キーだけで、渡す必要があります。それは、弁護士が議論するための10番目の草案ではなく、今までに行われるでしょう。

于 2012-08-23T21:49:42.163 に答える
2

優れた、よく書かれた、保守可能で堅実なアプリケーションは、それを開発するために使用されたテクノロジーに関係なく、それです。良いコードと悪いコードは、どの言語やフレームワークでも書くことができます。時間の経過とともに、開発者としての生活を楽にするツールが手に入りますが、最初から優れた開発者であれば、どのMVCフレームワークまたはXMLパーサーを使用しているかは関係ありません。

于 2012-08-23T21:20:38.467 に答える
0

あなたはあなたのために働くことは何でもすることができます。あなたが唯一の開発者であり、常にそうなるでしょう。そして、あなたが開発を行っている方法を深く理解しているなら、それを選んでください。

ほとんどの方法論は、長期的なメンテナンスを改善することに関するものです。メンテナンスは、プログラムの存続期間全体のコスト全体の95%を占めます。

ただし、アーキテクチャを混合することにより、アーキテクチャ間のインピーダンスの不一致が原因で修正が困難になる可能性のある非互換性に備えることができます。

MVCのモデルバインディングが問題なく機能するのに、なぜ独自のモデルバインダーを作成したのかについて少し混乱しています。または、独自のデータ注釈検証を行う必要があると感じた理由。しかし、それにもかかわらず、それはあなたのコードです。

MVCが気に入らない場合は、fubumvcやspring.netなどの使用を検討してください。

于 2012-08-23T21:13:17.857 に答える
0

私が関わった、または同僚がいる企業の中には、すべてが従来のASPから少なくとも.Net WebFormsの作成に移行している傾向があり、.NetWebFormsを実行している企業は現在MVCに移行しています。

于 2012-08-23T21:15:43.063 に答える
0

これには正しい答えはありません。

頭に浮かぶ唯一の答えは次のようになります:適切な仕事のための適切なツール

私の個人的な意見は、古典的なASP.NETは、昨日の非常に前日です。はい、彼らはあなたからHTMLを抽象化します、しかしねえ、彼らがこのMVCプロジェクトをすべて始めた理由があります-人々(専門家)は古典的なアプリケーションとしてウェブを書くことに満足していませんでした、レンダリングの制御も構造もありません。さらに、MVCは、従来のASP.NETに続くすべての最新のWebテクノロジーを考慮に入れています。Ruby on Railsは良い例です-DRY&COCの原則。MVCパターンはまた、アプリをより構造化し、関心の分離を提供します...

適切な仕事のための適切なツール

于 2012-08-23T22:29:03.200 に答える