問題タブ [architecture]

コレクション プロパティを持つオブジェクトを作成するたびに、それを行うための最良の方法を行ったり来たりしますか?

1. プライベート変数への参照を返すゲッターを持つパブリック プロパティ
2. 明示的な get_ObjList および set_ObjList メソッドは、毎回新しいオブジェクトまたは複製されたオブジェクトを返し、作成します
3. IEnumerator を返す明示的な get_ObjList と IEnumerator を取る set_ObjList

コレクションが配列 (つまり、objList.Clone()) とリストの場合、違いはありますか?

依存関係が作成されるため、実際のコレクションを参照として返すことが非常に悪い場合、なぜプロパティを参照として返すのでしょうか? 子オブジェクトを参照として公開するときはいつでも、子にプロパティ変更イベントがない限り、親が「知る」ことなく、その子の内部を変更できます。メモリリークのリスクはありますか?

そして、オプション 2 と 3 はシリアライゼーションを壊しませんか? これはキャッチ 22 ですか、それともコレクション プロパティがある場合はいつでもカスタム シリアル化を実装する必要がありますか?

汎用の ReadOnlyCollection は、一般的な使用に適した妥協案のようです。IList をラップし、アクセスを制限します。おそらく、これはメモリリークとシリアライゼーションに役立ちます。ただし、まだ列挙に関する懸念があります

多分それはただ依存しています。コレクションが変更されても構わない場合は、#1 に従ってプライベート変数を介してパブリック アクセサーとして公開するだけです。他のプログラムにコレクションを変更させたくない場合は、#2 および/または #3 を使用することをお勧めします。

問題に暗示されているのは、あるメソッドを別のメソッドよりも使用する必要がある理由と、セキュリティ、メモリ、シリアライゼーションなどへの影響は何ですか?

ユーザーとプレゼンスの独自の概念を持つ別のシステムを使用している場合、XMPP サーバー ネットワークへのブリッジを作成するための最も適切なアーキテクチャは何ですか? 私が知る限り、主な方法は次の 3 つです。

1. サーバーとして機能します。これにより 1 つのタッチポイントが作成されますが、互換性に影響があり、サーバーをエミュレートするシステムが複雑になる可能性があるのではないかと心配しています。

2. クライアントとして行動します。これは、システム内のユーザーごとに 1 つの接続が必要であることを意味しているように思われますが、これではうまくスケーリングできません。

3. XMPP ゲートウェイ プロトコルについて聞いたことがありますが、これがクライアント ソリューションより優れているかどうかは不明です。これが標準かどうかもわかりません。

任意の提案やトレードオフをいただければ幸いです。たとえば、これらのソリューションのいずれかを実行するには、ターゲット XMPP サーバー内でコードを実行する必要があります (私ができることではない可能性があります)。

アプリケーションでデータベースの例外をどのように処理しますか?
データを DB に渡す前に検証しようとしていますか、それとも単に DB スキーマの検証ロジックに依存していますか?
ある種の DB エラー (タイムアウトなど) から回復しようとしていますか?

いくつかのアプローチを次に示します。

1. DB に渡す前にデータを検証する
2. 検証を DB に任せ、DB 例外を適切に処理する
3. 両側で検証する
4. ビジネス ロジックのいくつかの明白な制約を検証し、複雑な検証を DB に任せる

どのようなアプローチを使用しますか? なんで？

アップデート:

議論が盛り上がって嬉しいです。
コミュニティの回答をまとめてみましょう。

提案:

• 両側で検証する
• クライアント側でビジネス ロジックの制約を確認し、DB にhamishmcn からの整合性チェックを行わせる
• ajmastrean からのDB に迷惑をかけないように、早めにチェックしてください
• 早期に確認して、Will のユーザー エクスペリエンスを向上させましょう
• hamishmcn からの開発を簡素化するために、DB と対話するコードを配置しておきます
• オブジェクト リレーショナル マッピング (NHibernate、Linq など) は、ajmastrean からの制約に対処するのに役立ちます
• Seb Nilsson からのセキュリティ上の理由から、クライアント側の検証が必要です

他に何か言いたいことはありますか？これは検証固有の質問に変換されます。「データベース関連のエラーのベスト プラクティス」の核となる部分がありません。どのエラーを処理し、どのエラーをバブルアップするか?

データベーストランザクションにどの程度依存していますか？

小さなトランザクションスコープと大きなトランザクションスコープのどちらが好きですか？

サーバー側のトランザクションよりもクライアント側のトランザクション処理（.NETのTransactionScopeなど）を優先しますか、またはその逆ですか？

ネストされたトランザクションはどうですか？

取引に関するヒントやコツはありますか？

トランザクションでの作業で遭遇した落とし穴はありますか？

あらゆる種類の回答を歓迎します。

私の以前の質問では、ほとんどのコメント提供者は、クライアント側とサーバー側の両方に検証ロジックがあることは良いことであることに同意しました。

ただし、問題があります。データベースとクライアントコード間で検証ルールの同期を維持する必要があります。

だから問題は、どうやってそれに対処できるかということです。

1つのアプローチは、ORM手法を使用することです。最新のORMツールは、サーバーに送信する前にデータ検証を処理できるコードを生成できます。

ご意見をお聞かせください。
この問題に対処するための標準的なプロセスはありますか？それとも、これはまったく問題ではないと思いますか？:)

編集：

皆さん、まずはご回答ありがとうございます。

明日はあなたの答えをまとめて、この場合のように質問のテキストを更新します

カップリングと結束の概念を簡潔な定義に要約しようとしています。誰かが私に短くてわかりやすい説明をしてもらえますか (ウィキペディアのこことここの定義よりも短い)? 彼らはどのように相互作用しますか？

ありがとう。

誰かが良い、短い例を持っていますか?

約1ヶ月前に入社しました。同社は規模がかなり小さく、かなり強い「スタートアップ」感を持っています。私は他の3人のチームでJava開発者として働いています。同社は主に、企業/業種の人々が互いにコミュニケーションをとるために使用するサービスを販売しています。

私がこれまで取り組んできた、そしてこれから取り組んでいる主なものの1つは、会社のメインWebサイトです。サービスの販売元であり、既存のユーザーはログインしてサービスを確認し、料金を支払います。新しいユーザーはトライアルにサインアップできます。 、など。現在、これはTomcatにデプロイされたJSPアプリケーションであり、データベースへのアクセスは、会社自体によって作成された永続化レイヤーを介して行われます。

私がここで繰り返して成長している欲求不満（そして私は仕事全体にかなり満足しているので、これは「ああ、私は私の仕事が好きではない」タイプの投稿ではありません）は、より大きなデザインの欠如またはこのWebアプリケーションのアーキテクチャ。このアプリは数十のJSPページで構成されており、サーブレットやBean、またはその他の種類のフレームワークにはロジックがほとんど存在しません。JSPページの多くは数千行のコードであり、jsp:include他のJSPページ、ビジネスロジックがHTMLに混在している、頻繁に使用されるコードのスニペット（Webサービス接続の取得など）が再利用されるのではなく切り取られて貼り付けられているなどです。言い換えれば、アプリケーションは混乱しています。

社内では、MVCにより適したものになるように、このサイトを再構築しようとしているといううわさがありました。開発者や上級者は、この現在のスパゲッティコードのパターンは持続可能ではないか、ユーザーに機能を追加するために非常に簡単に拡張できないことに気づき始めていると思います。上層部と開発者は、物事を完全に書き直すことを警戒しています（これは、既存の機能を書き直すのに数週間または数か月の作業を意味するため、正当な理由があります）が、（ゆっくりと）書き直すことについていくつかの議論がありました。サイトの特定の領域を新しいフレームワークに書き込みます。

アプリケーションとコードベースをこの方向に移動できるようにするための最良の戦略は何ですか？開発者として、私はどうすればこれを迅速に進めることができますか？仕事に就き、自分が書いたものはくだらないとみんなに言う、ぎくしゃくした新しい人のようには見えませんか？このようなことに遭遇したときに、自分の仕事の経験で使用した実証済みの戦略や経験はありますか？

典型的なビジネスアプリケーションの場合、AJAX を介したクライアント処理に焦点を当てる必要があります。つまり、サーバーからデータを取得してクライアントで処理するか、またはサーバーがほとんどの UI の処理を​​担当する、より古典的な ASP.Net アプローチを提案しますか?イベント？出発点となる優れた「デフォルトのアーキテクチャ」を思いつくのは難しいと思います。誰かが推奨できるオープン ソースのサンプル アプリケーションを持っているかもしれません。

C#、wpf、および .Net 3.5 について学習するために、C# 3.0 で単純なデスクトップ アプリケーションを作成しました。私のアプリケーションは基本的に csv ファイルからデータを読み取り、それを SQL サーバー CE データベースに格納します。sqlmetal を使用して、データベースの ORM コードを生成します。このアプリの最初の繰り返しは地獄のように醜く、リファクタリングの過程にあります。

それが私の質問につながります。C# でデスクトップ データベース アプリをどのように設計しますか? ベストプラクティスは何ですか?

sqlmetal によって生成されたコードを使用するデータベース アブストラクション レイヤー (DAL) を作成しますか? それとも、生成されたコードは十分に抽象化されていますか?

DAL パターンを使用する場合、シングルトンまたは静的メンバーのどちらにしますか? DAL パターンで View-Model-ModelView パターンを使用していますか?

これが長いオープンエンドの質問のように思えたら申し訳ありませんが、私は最近これについて多くのことを考えてきました. C# でエンタープライズ n 層アプリを設計する方法については多くの例を目にしますが、スタンドアロン デスクトップ アプリの設計についてはそれほど多くはありません。

コミュニティは、より小さな Facebook スタイルのプロジェクトに向けた方向性を絞り込んで、どの Web サイト構造/アーキテクチャを信頼するでしょうか?

質問がかなり広範/主観的であることを理解しています。しかし、Web 開発の分野では比較的新しいので、作業中のプロジェクトの例を見たり、そこから学んだりするだけで、ほとんどの場合非常に役に立ちます。また、それが私の心を吹き飛ばし、今後の課題の作成方法を変えることもあります。

後者の段落を念頭に置いて、コミュニティは見るべき場所/読むべき記事について何か提案がありますか?