前回、自明ではない .Net/C# アプリケーションに取り組んだときは、Castle Monorail を使用しましたが、全体としてその経験を楽しんでいました。.Net MVC の早期アクセス/プレビュー リリースはまだ利用できませんでした。多くの「Microsoft ショップ」は、「公式」ソリューションがより魅力的であることに気付くでしょう。モノレールから .Net MVC に移行した人はいますか?
どうやってスイッチを見つけましたか？
現在、最大の違いは何ですか？
Cheekysoft
質問する
1898 次
5 に答える
4
私はモノレールのユーザーですが、今のところ ActiveRecord ARSmartDispatchController で構築された利便性のおかげで、MonoRail + ActiveRecord の方が快適に感じています。ただし、MonoRail にはこれまでのところ適切なドキュメント ベースがないと言わざるを得ません (ドキュメントを書くのに十分な支援をしなかったコミュニティ参加者として、私は非難されるべき人の 1 人です)。
ここのコメントを見たように、ASP.NET MVC は WebForm ビュー エンジンを使用します。MonoRailにもそれがあると思いますが、かなり問題があると非難されていたので、ASP.NET MVC WebFormでの経験はどうですか.Webフォームコンポーネントをほとんどそのまま使用できますか、それとも基本的にほとんどを放棄する必要があります.それらのうち、より多くのテンプレート スタイルのアプローチに固執します (<%= や <%# など)。
于 2008-09-20T05:31:14.910 に答える
4
マイクロソフト ショップにとって好ましい方法であるとのご指摘がありましたので、切り替えを行いました。この切り替えは非常に簡単で、Mike が指摘したように、デフォルトで Web フォーム ビュー エンジンが同梱されていますが、MvcContribプロジェクトで brail と nvelocity で記述したビューを引き続き利用できると Mike が言ったように。ASP.NET MVC は、直接の ViewEngine に結び付けません。必要な ViewEngine を使用できます。これは必ずしも違いではないと思います。
私が見つけた最大の違いは、コントローラーとビューをグループ化したことです。MonoRail では、ControllerDetails 属性を使用してこれを簡単に行うことができました。独自のコーディングを行うことでこの制限を簡単に回避できましたが、機能が組み込まれていることを望みました。独自の ViewLocator を作成し、ActionFilterAttribute を作成することでそれを実現しました。
于 2008-08-24T20:18:06.290 に答える
3
まだ切り替えはしていませんが、両方のプラットフォームで開発を行い、切り替え前の分析を行っています。
最大の違いはView Engineのようです。私たちの Monorail スタッフは Brail ビュー エンジンを使用しますが、asp.net mvc にはビュー エンジンのような Web フォームが付属しています (ストック)。ただし、MvcContrib には、この分野で役立つ他のビュー エンジンがあります。
また、ViewComponents とビューの「ヘルパー」は、2 つのフレームワークでまったく異なる方法で処理されるようです。
于 2008-08-23T20:37:50.917 に答える
3
幸運なことに、私は組織で働いていないため、Microsoft から製品を出荷する必要があります。したがって、私はあなたの質問に直接答えることはできないかもしれませんが、MonoRail を使用するという点では、フレームワークのすべての部分を楽しんでいますが、ドキュメントやテスト スイートが不足しており、私をガイドしてくれます。
要するに、新しいフレームワークの学習に時間を費やしたくありませんが、それは密接に一致していますが (それぞれに独自の規則がありました)、ASP.NET MVC には、Dale Ragon ControllerDetail による機能の言及、ActiveRecord およびすぐ。
于 2008-09-25T14:58:23.647 に答える