メインスタックを.NETからJavaに変更する





Javaと呼ばれるエンタープライズ向けの最も人気のあるサーバー側プログラミング言語の観察と印象を説明したいと思います 。 私がよく知っている「類似の」 .NETプラットフォームとの比較と対照に関する観察と印象。 1年前、新しい子会社の未来が再び曖昧になり、技術スタックを変更するというアイデアが頭に浮かんだとき、この記事は非常に役立つと確信しています。 私は、グーグルが簡単なプログラミング言語の小さな技術的/文体的な違いには入らないようにしますが、むしろエコシステム全体で上から見ます。 だから、10年の経験を持つベテランのアフィリエイトの目を通してJava 。 猫をお願いします。



免責事項



むかし、 Microsoft SQL Server / Oracleの興味深い違いについて、「すごい、ブール型はありません」、「長いトランザクションは普通、真剣に」、「設定で自動コミットしないのはどうですか?」デフォルトでは」など しかし、内部の完璧主義者は、私が「十分に長く十分に勉強していなかった」、「どこか間違っているだろう」、「人々を笑わせようと急いでいる」などと考え続けました。 -すべてを「後」に延期すると、すべての印象が文字通り消えてしまい、書くことは何もありませんでした。 そこで、今回はあまり長く待たないことを決めました。さもなければ、再び書くことは何もないかもしれません。 そのため、不正確な点がある場合はそれを示すための個別のリクエスト。 そして次に、私は「varなしで書くのがいかに不便であるか」(Java 10はすでに先日待っていました)、「 拡張メソッドは存在しません」、その他の「 型消去 」および「 複数行ストリング」の卑劣さには入らないようにします。

エコシステム。



1. IDEと用語



.NETでは、選択は明白です-Visual Studio。 スタジオでの作業は、ソリューションでグループ化されたプロジェクト(プロジェクト)で行われます(後者は.sln、.json、次に.slnで、あまり重要ではありません)。 すべてが非常に簡単です。



Javaの世界では、現在、IDEとして注目されているのはIntellij IdeaEclipseの 2人です。 「ソビエト後の空間」で最初に勝った。 外国の著者にとって、日食はすべての生き物よりも生きています。 使用するもの、メモ帳でさえ違いはないように思えますが、この場所では用語の問題がすぐに発生します。



Eclipseでは 、最高レベルはプロジェクトで構成されるワークスペースです。

Ideaでは 、最高レベルはプロジェクトであり、 モジュールで構成されています



さまざまなIDEを使用する開発者とのコミュニケーションに使用される用語は不明です。 多くの場合、「コレクター」という用語で通信するのが習慣です。 そのため、たとえばmavenの場合、ディストリビューションはモジュール( module )から組み立てられ、モジュールはpomnickにグループ化されます。



私が正しく理解していれば、この混乱は以前の言語の「すぐに使える」モジュール性の欠如が原因であり、各ツールは以前は適切と思われる用語で「モジュール性」を高く評価していました。



それとは別に、 Beansに注目したい。 .Netでは、コンテナに登録されている通常のクラスに新しい用語を導入することは誰にも起こりません。 多くのプロジェクトでは、2018年でもコンテナはまったく使用されていません(はい、それを見るのは痛いですが、私は何度も見ました)。 反対に、 Javaの世界では、これはコンテナカルトであり、ビンの観点から通信することが習慣になっています。



2.プロジェクトの組み立て



まず第一に、新しいエコシステムでは、多少異なる功利主義的な「カット」が印象的です。 いくつかのケースでは、大きく、いくつかで-小さい。



.Netの世界では、 nugetはパッケージ/依存関係管理ツールとして使用され、 msbuildはアセンブリに使用されます。



Javaでは、すべてが1つのツールに接着されます(ただし、ここでもMavenまたはGradleの選択肢があります)。 それぞれに多数のプラグインがあります。 最初のものは血まみれの混乱で支配的です。



コレクターには非常に便利なラッパーがあり、これを使用すると、開始してビルドすることができます(異なるマシンで必要なバージョンのmsbuildの検索に出会った人は誰でも私を理解するでしょう)。



Dotnetは現在、同じ方向(hello、 Cake )に移動しようとしています。



3.アプリケーションフレームワーク



これは、Javaプラットフォームの絶対的な優位性です。 2つの主なモンスターがあります。EJBと、巨大なエコシステムと「アラウンド」プラクティスを備えたSpringです。 2番目が支配的です。 時間が経つにつれて、それも大きく複雑になったため、フレームワークのフレームワークであるSpring Bootを思い付きました。 敬意を表したいと思いますが、これは本当に人生をずっと楽にします。



.Netにはこれは何もありません。 しかし、「各プロジェクトごとに独自の方法で」自転車の発明があります。 開発者の好みに合わせて適切なDI / IoCコンテナーを選択するまで(開発者がコンテナーの存在を認識している場合)、トランザクションの管理方法を決定する(開発者がどのトランザクションが再度行われ、誰かがSQL Serverで自動コミットを無効にすると推測した場合) 。 ASP.NET MVCがSpring MVC(Spring Frameworkのほんの一部)に似ている場合を除きます。



4.アプリケーションサーバー



そして、 IISは 1つのモノリシックでした。 そして、彼らはSystem.Webが悪いことに気づきました。 そして彼らはOWINを思いついた。 ただし、これからWindows用IISの適切な代替が表示されませんでした(はい、Kestrel for .Net Coreについて知っています)。



Javaでは、選択肢が膨大であり、サーブレットAPI、または最新のリアクティブストリーム(hi .Net Async Controllers)と多くの実装がありますが、Tomcatは最も人気のある「ボックス化」実装の1つです。



5.コミュニティ



Java Community Process 、それだけです。 関係者がプラットフォームの新しいバージョンの議論と形成に参加できる正式なプロセス。



わずか15年後、Microsoftはそれが良かったことに気づき、「生き方」を世界に口述するのをやめる時が来ました(現在解散したMicrosoft Patterns and Practicesグループを覚えていますか?)そして、アナログ.NET Foundationを思いつきました。



6.データベースを操作する



2018年も引き続きJPQLを使用し続ける理由は、私にとってまだ十分に理解された瞬間ではありません。 私が見つけた唯一の説明は、タイプされた基準が恐ろしく冗長であることです。



これは、アフィリエイトがより幸運な数少ない場所の1つです。 .NETのデータベースクエリの99%は、型指定されたコンパイル時LINQで記述されています。



はい、私はjOOQについて知っていますが、少なくとも生産を連想させる何かでその使用を見たことはありません。 おそらく別の理由で、JSRを使用しないセミペイドリメイクだからでしょう。



7. XML地獄



Javaがxmlのトンであるという誤解は今でも一般的です。 しかし、生態系開発の現在の段階では、そうではありません。 まったく逆です! 1行のxml(hello Spring Boot)を使用せずにJavaでWebアプリケーションを記述できます。また、.Net(hello web.config、「本質的に」同じweb.xmlですが、configと混合)でそれを行うことはできません。 。



結論



彼が望むなら、誰でも自分でそれをするでしょう。 白黒はなく、プラス、マイナス、妥協はどこにでもあり、すべてのプラットフォームにあります。 同じプラットフォームで何年も開発した後、メインのプログラミング言語とエコシステム全体を変更することは非常に興味深く、便利で、文字通り新鮮な息吹のようです。 さまざまな方法で、さまざまな角度から多くの概念的および建築的なものを見始めます。



PS: KPDVについて-古いが、それでも面白いビデオ



All Articles