48

1 日おきに別の Java Web フレームワークを学ばなければならないことにうんざりしています。
JSP、Struts、Wicket、JSF、JBoss Seam、Spring MVC など、数え切れないほどのフレームワークが同じ問題に対処しようとしています。しかし、どれも根本的な問題を本当に解決するものではありません。そのため、常に新しい問題が次々と発生しています。

シンプルな作業をシンプルにするため、ほとんどの製品は第一印象で非常に明るく輝いて見えます。
しかし、実際のユースケースの実装になるとすぐに、問題が発生します。
多くの場合、フレームワークは何の助けも提供しませんが、フレームワーク自体のロジックと環境に従って物事を実装することを強制することで、助けを妨げ、選択肢を制限しています。

要するに、フレームワークを使用する場合、次の欠点があります。

  1. ほとんどの場合、学習曲線は急勾配であり、開始する前に、まず非常に学術的な概念を理解し、一連の構成ファイルの意味と場所を知る必要があります。
  2. ドキュメントは通常、多かれ少なかれひどいものであり、公開されているオンライン リファレンスがないか、どうしようもなく時代遅れであり、互換性のないさまざまなバージョンまたはこれらすべてが混同されており、多くの場合、役立つ例が提供されていません。
  3. フレームワークは無数のクラスで構成されており、ソースを閲覧するだけでは使用目的を理解することは事実上不可能です。
  4. したがって、全文検索がなく、持ち運ぶのが重いため、ユーザーインターフェイスが悪い「XYZ in action for dummies in 21 days」のような本を購入する必要があります。
  5. このフレームワークの 1 つを実際に使用するには、他に使用できない愚かで役に立たない情報で頭がいっぱいになるまで、適切なクラスとメソッド名を覚えることによって、フレームワークが必要とする方法で物事を行う方法を暗記する必要があります。 .
  6. 大きなオーバーヘッドが発生し、アプリケーションのパフォーマンスが低下し、実際に何が起こっているのかを理解しようとすると、脳が麻痺してしまいます。
  7. 現実の世界では、生産的であることのプレッシャーのために、通常、何か新しいことに慣れる時間はありません。アプローチを行うことによるこの学習の結果として、新しいツールとその可能性を実際に理解するのではなく、次のタスクを完了するための最速の方法だけを常に探します。
  8. 標準に従うことで、プロジェクトに不慣れな人々がすぐに始めることができるという議論は、私の見解では有効ではありません。同じ会社内であっても、すべてのプロジェクトが異なるフレームワークを使用するためです (少なくとも私の場合)。

アルバート・アインシュタインの次の引用は、ここに非常によく当てはまるように思えます。

「問題を作ったときと同じ考え方で問題を解決することはできません。」

コーディングがまだ楽しくて生産的だった古き良き PHP コーディング時代に戻ると、私はほとんどのことに対して独自のフレームワークを作成し、それを 1 つのプロジェクトから次のプロジェクトにコピー アンド ペーストして採用していました。
このアプローチは非常にうまくいき、開発が高速になり、オーバーヘッドがまったくなくなり、実際にはほとんどの Java フレームワークよりも強力なフレームワークになりましたが、1 つのファイルに数百行のコードといくつかの単純な mod_rewrite ルールしかありませんでした。
これで Web 開発のすべての問題が解決されたわけではありませんが、シンプルで、迅速で、的を射たものでした。
現在のプロジェクトの要件に完全に適合すると同時に、簡単に拡張でき、オーバーヘッドがゼロであるため非常に高いパフォーマンスが得られました。

では、なぜこのフレームワークを使用するのにそれほど手間がかかるのでしょうか? それらをすべて捨てて、ルーツに戻らないのはなぜでしょうか?
明日からまた新しいフレームワークで次のプロジェクトを始めるとき、上司に何と言えばいいですか?
それとも、本当に違いを生むフレームワークがあるのでしょうか?
または、私が無視したいくつかの隠された利点?

4

12 に答える 12

35

コーディングがまだ楽しく生産的だった古き良きPHPコーディングの時代に、私はほとんどのもののために独自のフレームワークを作成し、プロジェクト間でコピーして貼り付けて採用していました。このアプローチは非常にうまく機能し、開発が迅速になり、オーバーヘッドがまったくなく、実際には他のほとんどのJavaフレームワークよりも強力なフレームワークが得られました。

1秒ではないと信じて許してください。

ただし、1つのファイルに数百行のコードといくつかの単純なmod_rewriteルールが含まれています。これは確かにWeb開発のすべての問題を解決するわけではありませんでしたが、単純で、高速で、的を射たものでした。

つまり、基本的には、数か月または数年にわたって独自のフレームワークを開発し、独自のニーズに合わせて調整し、それをよく知っているため、非常に高速に動作する可能性があります。

それでも、なぜ他の人が同じことをし、その結果を誰もが使えるものに変えようとするのか理解できませんか?

あなたが開発したこの素晴らしいフレームワークはどこにありますか?非常に強力で使いやすい場合、専用のコミュニティ、数千のユーザー、数百のサイトがそれを使用して開発されていますか?

すべてのプロジェクトは、同じ会社内でも異なるフレームワークを使用しています(少なくとも私の場合)

さて、それはあなたの問題です。各プロジェクトの後に、各フレームワークで得られた専門知識を捨てるのはなぜですか?

アイデアは、1つのフレームワークを選択し、それを複数のプロジェクトに適用して、それに習熟することです。フレームワークを学ぶためにある程度の時間を費やす必要があります。そうすれば、より高いレベルで作業できるようになるため、時間を節約できます。

于 2009-04-23T11:18:51.340 に答える
20

独自のフレームワークを考え出す際の問題は、確立されたすべてのフレームワークがすでに遭遇して対処したのと同じ間違いをすべて犯してしまうことです。これは特にセキュリティに関して当てはまります。

スタックオーバーフローでWMDを実装するときに考慮しなければならないことについて、Jeffとその人たちに聞いてください。ゼロから実装するのではなく、プロジェクトで作成したものを使用したいと思います。それはほんの一例です。

于 2009-04-23T11:23:32.263 に答える
12

これは、スレッドからのKevの引用です。最も物議を醸すプログラミングの意見は何ですか? これは本当にうまくここに収まります:

「エンタープライズ」フレームワーク全体は煙と鏡だと思います。J2EE、.NET、Apache フレームワークの大部分、およびそのようなものを管理するためのほとんどの抽象化は、それらが解決するよりもはるかに複雑なものを生み出します。

通常の Java または .NET OMR、または退屈で単純なタスクを解決する「魔法」を行う最新の MVC フレームワークを使用してください。最終的には、検証と迅速な作成が困難な大量の見苦しい XML ボイラープレートを作成することになります。それらの半分が他の API の作業を統合するためだけのものである大規模な API、リサイクルが不可能なインターフェース、および Java と C# の柔軟性のなさを克服するためだけに必要な抽象クラスがあります。そのほとんどは必要ありません。

独自の厳しい記述子構文を持つすべての異なるアプリケーション サーバー、過度に複雑なデータベースおよびグループウェア製品についてはどうですか?

これのポイントは、その複雑さ==悪いということではなく、不必要な複雑さ==悪いということです。私は大規模なエンタープライズ インストールで作業を行ってきましたが、その一部は必要でしたが、ほとんどの場合でも、ほとんどのユース ケースを解決するために必要なのは、いくつかの自家製スクリプトと単純な Web フロントエンドだけです。

私は、これらすべてのエンタープライズ アプリケーションを単純な Web フレームワーク、オープン ソース DB、および簡単なプログラミング構造に置き換えようとします。

于 2009-04-24T09:17:16.103 に答える
11

もちろん、問題はJavaフレームワークだけではありません。要件をドキュメント/ビューモデルに詰め込もうとして悩んでいるC++MFCプロジェクトの数を数え切れませんでした(これは実際にはテキストおよびグラフィックエディターでのみ機能します-データベースアプリケーションは特に難しいです) 。

フレームワークをうまく使用する秘訣は、フレームワークに一致するようにアプリケーションを変更することであり、その逆ではありません。それができない場合は、フレームワークの使用を考えないでください。信頼性が高く、十分に文書化されたユーティリティライブラリを使用して、アプリを最初から作成した場合よりも手間がかかります。

于 2009-04-23T11:24:28.113 に答える
9

Web アプリケーションを構築するたびに、ソケットと HTTP を処理する必要があると言っているのですか!

サーブレット コンテナ自体はフレームワークと見なすことができます。これは、これらの面倒な詳細をすべて処理し、はるかに単純なサーブレット/フィルタ/リスナ (つまり、アプリケーションに固有のフレームワークの「拡張」) を作成する必要があるためです。

すべてのフレームワークが試みているのは、平凡で、繰り返し可能で、エラーが発生しやすい、手間のかかるコードを、楽しいアプリケーション固有のコードから分離することだけです。

ただし、小規模なアプリケーションの場合は、JSP とサーブレットのみを使用するモデル 2 MVCアプローチを使用するだけで済みます。

例:

class MyController extends HttpServlet {
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ... {
        MyBean model = // do something
        request.setAttribute("model", model);
        request.getRequestDispatcher("/view.jsp").forward(request, response);
    }
}

次に、アプリがより洗練されるにつれて、Spring MVC を使用して、コントローラーやビュー リゾルバーなどのより疎結合 (したがって、より柔軟) を提供することを検討できます。

于 2009-04-23T12:18:15.253 に答える
7

トリックを行わないさらに別のフレームワークに直面したときのあなたの痛みを共有します。

10年間のjsp、struts、EJB、EJB2、struts2、jsf、そして最近ではすべての新しいWebサービスframworks、xslt horrors、wsdl-firstの悪夢を乗り越えてきたので、私は間違いなくうんざりしています。

フレームワークには多くの問題があります。それらはリークするため、詳細を学ぶ必要があります-社内フレームワークには莫大なコストがかかり、外部フレームワークのコストも(ただしはるかに少ない)提供されることはめったにないため、それを使用すると、xml構成の膨大なチャンクを作成し、修正に数日を費やすことになりますコードエディタを支援するお気に入りのコンテンツですぐに見た大文字と小文字およびスペルの誤り。

たぶん答えは、問題を解決しようとするが世界を再定義しない、それほど豪華ではないツールキットを見つけることですが、基本的なアプリケーションモデル(http上のhtml)は厄介なので、それも難しいです-せいぜい。

周りには多くの複雑な問題があるように思われるという事実を追加します。退屈な単純な問題を複雑な(しかし難しい)興味深い問題(上記のEric Sinkのソフトウェア開発の公理の変形かもしれません)と交換することに夢中になっているようです。

それをすべて知っている開発者の傲慢さを追加し、あなたのためにすべての難しい問題を解決するために新しいフレームワークを書くことを躊躇しないでください。

私は.NETの経験はありませんが、.NETの世界は理論家や複雑な人で混雑していないようで、VBの長引く悪臭が彼らを怖がらせているのかもしれませんが、誰かが私に彼らが彼らのメイヴンで1500時間を費やしたと言うのを聞くたびにconfig(hello?)、履歴書から「java」を削除することを真剣に検討しています。

...もう一度質問は何でしたか?違いを生むフレームワークはありますか?

編集-ストライプとQueryDSLを追加しました。

実際にJavaで開発しているという事実のために、QueryDSL + HibernateまたはOpenJPA(アノテーション付き)でStripesまたはGWTを試し、wsdl-first Webサービス、xml中心のフレームワーク、EJBおよびESB(ビールではありません)可能な限り。

于 2009-04-23T14:24:25.807 に答える
3

私はかつて、JSFでそれを実装しようとするプロジェクトに取り組む必要がありました。それは悪夢でした。

作業時間のほとんどは、物事をコンパイルするためだけに費やされました。コンパイルされたものの半分以上が機能しなかったという事実は別の話でした。チュートリアルはほとんどありません。ドキュメントは基本的に自動化されたソースコードのエクスポートであり、人間のコメントはありません。どうすればこのように機能することが期待できますか?

いくつかのフレームワークのうち、Sunだけがコンパイル可能な新しいプロジェクトを作成できました。もう1つは、コンパイル可能な状態になるまでに何日もかかった大量のデータしか生成できませんでした。

ウェブはほとんど静かでした。どの検索でも、検索結果は20ページ以内で、最初の1〜3ページが役立ちます。見つかった関連するものでは、半分の人が助けを求めて泣いており、残りの半分は助けを求めて泣いたと宣言しました。誰も来ませんでした。時間と興味を失い、そのテクノロジーを落としました。

そのため、時間をかけて、たとえばASP.NETで数週間で実行できるような単純なものだけを作成しました。

次に、代替のJSFフレームワークを検討しました。驚いたことに、それらはすべてまったく互換性がないことがわかりました。

当然のことながら、JSFを落とした人たちにも加わりました。

于 2009-04-23T11:33:30.650 に答える
3

対抗点を考えてみましょう。私は現在、JSP 標準以外のフレームワークを使用していないショップで働いています。誰もが物事を行う方法が異なり、分離などの概念や検証などのセキュリティの問題については非常に緩いです。

フレームワークを使用することで自動的に優れたコーダーになるとは思いませんが、ほとんどのフレームワークで実装されている標準的なデザイン パターンを使用し、検証などのユーティリティ機能に簡単にアクセスできるようにすることで、あなたがより優れたコーダーになる可能性が高いと思います。特定の基準までコーディングすることを余儀なくされました。

Web アプリケーションの設計では、毎回車輪を発明しているわけではないため、一般的なタスクに独自のソリューションを展開するか、フレームワークを使用することになります。独自のフレームワークを作成するのではなく、一般的に使用されているフレームワークを使用することで、十分にテストされた柔軟な基盤となるコードを取得できると想定しています。

独自のソリューションを学術的な追求として展開することは何も悪いことではありませんが、私が費やすことができるよりも多くの時間を堅牢なソリューションに費やしている人がいることを受け入れます. たとえば、log4j を例にとると、ロガーをロールするのは非常に簡単ですが、log4j は十分にテストされ、維持されており、独自のロガーをほとんどロールすることができない程度まで柔軟性とパフォーマンスを改善するために時間がかかりました。最終結果は、堅牢でありながら、最も基本的なアプリケーションでも使用できるほどシンプルなフレームワークです。

于 2009-04-23T15:47:18.547 に答える
2

私にとってうまくいったのは、聞いたWebフレームワークを学ぶだけでなく、それを見て、コードが快適になるかどうかを確認し、stackoverflowやフォーラムでその長所と短所を確認してから、それを学び、学ぶべきです。それは良いです、そしてあなたがその壊れたまたは明白な時代遅れを感じるまでそれを続けてください。あなたが書いたWebフレームワークはどれもそれ自体が優れており、それが何をするのかを「本当に」知っていれば、一緒に作業するのは楽しいものです。そうでなければ、あなたはただコンパスのない砂漠をさまよっているだけです!また、21日間の本は、フレームワークやテクノロジーを習得しないための確実な方法であることがわかりました。ドキュメントは、af / wを採用する際に考慮すべきことです。コードを自分で見回す場合にも役立ちます(実際、これは、奇妙な動作に直面したときに最も役立つものです。

1-では、なぜこのフレームワークを使用するのが面倒なのか、それらをすべて捨ててルーツに戻ってみませんか?

ルーツに戻ると、同じことを何度も繰り返すコードを書き直します+これらのf / wのほとんどはオープンソースであるため、自分のf/wを単独で実行するよりもメンテナンスの方が適している可能性があります。

2-明日、新しいフレームワークを使用して次のプロジェクトを再開するときに、上司に何を言うべきですか?

このf/wを使用するのはこれが初めてです。なぜこのf/wを使用する必要があるのか​​わかりません。私はすでにXを知っていて、本当に上手です。私がこのf/wを学ぶためのコスト、そのようなaf/wを知らないために行わなければならないやり直しのコストを心に留めておいてください。Xを使用する方が良いと思います。これが特定の要件である場合は、Xを使用して戦い、前のメモを実際に記載する必要がある場合にのみ実行する必要があります。

それとも、本当に違いを生むフレームワークはありますか?

あなたがコードを書く方法ではなく、あなたの考え方に取り組む人だけです(MVCパターンを強制する黄金時代の支柱を考えてください)。

または私が無視したいくつかの隠された利点?

どんなtbhも考えることができません。

于 2009-04-23T11:15:27.527 に答える
1

PHPでも同じ問題があります。信頼できるフレームワークよりも多くのフレームワークがあり、それぞれが最高で最高です(ただし、いくつかのヒントがあります。純粋なPHP5設計とPHP4の互換性、Rails哲学(柔軟性のないフォルダー階層、自動生成)コード)対ライブラリアプローチ...)そしてあなたはあなたのコードを書くよりも可能性を探しそして探求することに多くの時間を費やします!
しかし、PHPでは、I18Nサポート、プラグインの統合、セッションと認証の管理、データベースの抽象化、テンプレート、Ajaxサポートなどの一般的な問題を事前に解決できます。初心者のための一般的な罠で。

もちろん、Javaフレームワークにもいくつかのヒントがあります。大きいか小さいか。十分に文書化されているかどうか?広く使用されているか、機密ですか?XMLファンのためかどうか?など
ほとんどのフレームワークは、学習時間が大きな問題ではなく、スケーラビリティと展開の容易さが重要である大規模なプロジェクトを対象としていると思います。小規模なプロジェクトではおそらくやり過ぎです。

このようなフレームワークには、モノリシックフレームワークではなく、ゆるく結合されたライブラリの一貫したセットを実行することを目的とする傾向もあります。これは、PHPの世界では、Zendフレームワークの場合です(「フレームワーク」という単語の使用を拒否する人もいます...)。
したがって、邪魔にならずに「一般的な問題の解決」の問題を解決します。

于 2009-04-23T11:18:25.787 に答える
0

しかし、あなたがおっしゃったいくつかの点については同意しませんが、退屈な仕事に関しては同意します。

はい、すべてのWebアプリケーションは、フォームの表示、データの収集、検証、データベースに保存するためのデータの送信、検索フォームによる保存データのフィルタリング、テーブルへの結果の表示、操作用の1つ以上のレコードの選択(CRUD、またはデータベース内のステータスの変更に関するすべてのビジネスアクション)。

しかし、私はたった4年間、そしてもちろん4年間の学術研究で働いています。アルゴリズムを発明していないので、このタイプの開発は退屈だと思います。もちろん、新しいフレームワークを見つけたときに幸せになり、AIエンジンの1つをアプリケーションに統合すると幸せになりますが、最終的にはこの作業がうまくいくと感じていますダミーの作業、または機械の作業と言えば、なぜこれらすべてを自動化しないのですか。

はい、別のフレームワーク;)MDAモデル駆動型アーキテクチャは、簡単に言えば、PIM(プラットフォーム独立モデル)からPSM(プラットフォーム固有モデル)への変換、つまり、UMLからコードへの変換に関するものです。

AndroMDAなどのMDA仕様を実装するフレームワークがいくつかあり、クラスダイアグラム、ユースケース、シーケンスを取得するカートリッジがあるため、モデリングが得意であるだけでよいため、これにより学習曲線とテクノロジの変更の問題が解決される可能性があります。ダイアグラム、およびアクティビティダイアグラムを作成し、データベース作成スクリプト、POJO、休止状態マッピング、Spring / EJB、JSF / Struts、.NETコードを生成します。

もちろん、そのようなフレームワークはコードの100%を生成しませんが、大きな割合を生成します。もちろん、このフレームワークが要件の複雑でトリッキーなシナリオを解決するかどうかを尋ねます。今日はノー、明日はイエスと言います。

それで、なぜあなたと私はこの素晴らしいフレームワークの開発に投資しないのですか。

于 2009-04-23T11:22:23.953 に答える
0

では、私たち全員がすべてのプロジェクトで車輪を発明したほうがよいと思いますか?

過剰なフレームワークを問題として見るかもしれませんが、それによって独自のセットを選択することが難しくなります。しかし一方で、すべてを試す必要はありません。そうしたとしても、それらのいくつかを好むことになります。ORM 用のお気に入りのフレームワーク、Web 開発用の別のフレームワーク、IoC などがあります。

いくつかのフォーラムを読んで、どれが最も人気があるかを知ることは役に立ちます。それらは理由で人気があるに違いありません。たとえそれが正しい理由でなくても (技術的に優れているなど、流行語の過負荷などのためにマネージャーの間でのみ人気があるかもしれません)、上記のフレームワークの知識は役に立ちます。それを使用するいくつかのプロジェクトに参加します。

さらに、独自のフレームワークを作成する代わりにフレームワークを使用すると、多くの問題を回避できます。バグは常に作成者によって発見され、解決されるとは限りません。これは、フレームワークのユーザーによってよく行われます。あなたは、PHP で独自のプライベート フレームワークを作成したと言いました。バグがないわけではなかったに違いありませんが、あなたは唯一のユーザーであり、唯一のコーダーだったので、知らなかったのかもしれません。

于 2009-04-23T14:53:38.063 に答える