問題タブ [architecture]

おそらく 50% のカスタム機能で構成されるアプリケーションの構築を伴うプロジェクトがいくつかありますが、その後、たとえば wiki、フォーラム、および既に発明されていて、私たちが作成していない「車輪」であるその他のコンポーネントを取り込みます。最初から書き直したい。

これらのサードパーティ アプリケーションには、通常、独自のデータベース、テーマ、および認証システムがあります。私の経験では、シングル サインオンや共通のテーマ、または複数のサブアプリ内のエンティティ間でのタグ付け/検索などを機能させることは、非常に困難な問題です。この種の統合プロジェクトのベスト プラクティスにはどのようなものがありますか?

これまでのところ、私たちのアプローチは慎重にコンポーネントを選択しようとしてきました。できれば HTTP (REST や SOAP など) を介して、明確に定義された API を持つものを選択してください。そのように機能するフォーラム）。私たちの多くは最近ますます頻繁になっていると思うので、これをやろうとしている人に人々が与えることができる提案はありますか?

ビジネスの支持者が Web ベースのシステムにリアルタイムという用語を使用しているのを聞くと、気が狂いそうになります。私は部屋で夢中になり、「ウェブ上にリアルタイムなどというものはありません! 私たちはロケットの打ち上げ/船のナビゲーション/飛行機の自動操縦のビジネスではなく、銀行業に携わっています!」と唱えています。

リアルタイム、またはその恐ろしいハイブリッド、ほぼリアルタイムよりも優れたパフォーマンス仕様を持っている人はいますか?

もちろん、単純な箇条書きリストやマインドマップを使用することもできます。しかし、より優れた、よりインタラクティブな方法が必要です。ウェブサイトのアーキテクチャを開始するときに何を使用しますか?

トレーニングと旅行のリクエストを提出する必要がある時期が近づいています。今後 12 か月以内に、コーディングやソフトウェア開発、ベスト プラクティス、システム アーキテクチャなどの改善を目的としたカンファレンスやクラスを探しています。それ以外の承認は得られないため、米国またはカナダで開催する必要があります。 .

ここに私が見つけたいくつかがありますが、他の提案を探しています。また、これらのいずれかについてのフィードバックも歓迎します。
ソフトウェア プロセス シンポジウム
ソフトウェア開発のベスト プラクティス
より良いソフトウェア カンファレンス
IASA 接続

IASA イベントは私に最も近いように見えますが、リクエストしてスケジュールするのに十分なリード タイムがありません。

（私は.NET開発者ではなく、他の環境に縛られていないことを明確にすることから始めます。）

最近、ロンドン証券取引所が丸一日下落したと聞きました。また、ソフトウェアは.NETで作成されていると聞きました。この時点まで、彼らは忙しい日にパフォーマンスの打撃を経験するでしょう。人々は.NETを非難しているようです。

この話については議論したくありませんが、.NETはどのように拡張できるのかという疑問が浮かびました。.NETには大きすぎますか？

クライアント/サーバーアプリケーションをサポートするために、管理ポータルWebサイトを構築する必要があります。私たちは.Netショップなので、ASP.Netでそれを行うのが従来の方法です。ただし、Silverlight 2は、リリース日のかなり前にベータ版からリリースされる予定です。代わりに、サポートするWCFバックエンドを使用して、Webサイト全体をSilverlightで構築することを検討する必要がありますか？

ポータルの主な機能は次のとおりです。ユーザー、グループ、および権限の構成。ユーザープロファイル設定の構成。アプリケーションをサポートするために必要なファイルのファイルのアップロードとダウンロード。

このアプローチを採用する主な理由は、WPFとWCFの経験は豊富ですが、ASP.Netの経験はほとんどないためだと思います。いずれにせよ、ASP.NetまたはSilverlightを学ぶ必要があり、Silverlightを学ぶことは、現在のスキルのより自然な拡張のようです。

StackOverflowersの経験から大きなノーノーはありますか？大きなプラスは何ですか？

さまざまなタイプの多くのアイテムで構成されるシステムのモデルを構築するための一般的な解決策は、各モジュールが特定のタイプを担当するモジュラー システムを作成することです。たとえば、ウォンバットのモジュール WombatModule:IModule があり、IModule インターフェイスには GetCount() (ウォンバットの数を見つける) や Update() (すべてのウォンバットの状態を更新する) などのメソッドがあります。

よりオブジェクト指向のアプローチは、すべてのアイテム タイプのクラスを持ち、すべてのアイテムのインスタンスを作成することです。これにより、クラス Wombat:IItem が Update() のようなメソッドで作成されます (この 1 つの wombat を更新するため)。

コードの観点から見ると、違いはごくわずかですが、実行時間は大幅に異なります。モジュール指向のソリューションは確かに高速です。オブジェクトの作成が少なくなり、すべてのウォンバットに共通する操作の最適化が容易になります。

タイプとモジュールの数が増えると問題が発生します。各モジュールがいくつかのアイテムしかサポートしないため、パフォーマンス上の利点のほとんどが失われるか、モジュールの複雑さが大きくなり、1 つの一般的なタイプのわずかに異なるアイテム (太ったウォンバットとスリムなウォンバットなど) に対応するようになります。または両方。

WombatModule が非表示の Wombat オブジェクトのコレクションを保持し、それらのメソッドをループで実行するだけである場合、少なくとも一度は状態が悪化するのを見たことがあります。

パフォーマンスが長期的な開発ほど問題にならない場合、アイテムごとのオブジェクトの代わりにモジュールを使用するアーキテクチャ上の理由を特定できますか? 私が見逃している別の可能性があるかもしれませんか？

インターフェイスと実装を分離するというアイデアが気に入っています。しかし、どのように分離しますか？インターフェイス定義は別の .Net アセンブリにありますか? ソリューションのすべてのインターフェイスを定義する単一のプロジェクトはありますか? そうでなければ、インターフェースの循環依存に問題がありますか?

ORM ツールを導入すると、アーキテクチャがよりクリーンになると思われますが、効率化のために、ORM ツールをバイパスして、JDBC Result Set を反復処理することが時々あります。これは、よりクリーンなアーキテクチャではなく、調整されていないアーティファクトのもつれにつながります。

これは、無効なコンテキストでツールを適用しているためですか、それともそれよりも深いですか?

ORM アプローチを完全に独り占めできるのはいつですか?

どんな洞察も大歓迎です。

背景の少し:

私の環境では、約 50 台のクライアント コンピューターと、かなり強力な SQL Server が 1 台あります。

50 クライアントすべてが常にデータにアクセスしているデスクトップ アプリケーションがあります。

プロジェクトのデータ モデルは、明確性、効率性などのさまざまな理由から、多くの再編成を経てきました。

私のデータモデルの歴史

1. JDBC が直接呼び出す
2. Pojo 間の関係のない DAO + POJO (基本的に JDBC をラップ)。
3. 遅延読み込みを実装する POJO 間の関係を追加しましたが、DAO 間の呼び出しを非表示にするだけです
4. Hibernate の時流に飛び乗ったのは、Hibernate の時流に飛び乗ったのは、Hibernate がデータ アクセスをいかに「シンプル」にするか (POJO 間の関係が些細なものになった) を見てからでした。
5. セッションを長期間開いたままにしておくのはデスクトップアプリケーションだったので悪夢だったので、最終的には多くの問題を引き起こしました
6. Hibernate を使用しながら、DAO カーテンの背後で直接 JDBC 呼び出しを行うことができる、部分的な DAO/Hibernate アプローチに戻りました。

私は現代のテキストエディタのためのデザイン\アーキテクチャのガイダンスを探しています。

最新のテキストエディタとは、次のことを意味します。

• 構文の強調表示をサポートしています
• オートコンプリートがあります（IntelliSenseのようなもの）
• 高度なナビゲーション機能（インクリメンタルサーチなど）を備えています

次のプロパティがプラスになります。

• 管理言語（Java、任意の.NET言語）で実装
• モジュラーアーキテクチャ
• アドインのサポート

テキストエディタ関連のデザイン\アーキテクチャドキュメント\記事、オープンソースプロジェクトへのリンクに 非常に興味があります。

一般的な推奨事項、OOP/デザインパターンの本の広告には興味がありません。

現在、 SharpDevelopコードエディタのソースコードを分析しています。同様のプロジェクトへのリンクをいただければ幸いです。