問題タブ [application-design]

ジェネリック インターフェイスで使用される DTO クラスの基本クラスが必要です。

しかし、DTO クラスには共通点がありません。それらは、いくつかのプロパティを含む単なるダムクラスです。

私たちは、誰かがレコードを追加する単純なWebベースのシステムを構築しています。たとえば、CMSページは、Webサイトに表示される前に担当者によって承認されます。

その後、作成者がそのページを後で編集することを決定した場合、ライブコピーに基づいてドラフトを作成します。承認されると、古いライブページが置き換えられます。

完全なバージョン管理を行うことを考えましたが、1。ドラフトだけ、2。ライブだけ、または3.1つのドラフトと1つのライブを用意するだけでこれを簡単に保つことができると信じています。

この機能は、ページだけでなく、複数の「モノ」に必要です。

最後に、質問：これら2つのレコードを同じテーブルに格納する方がよいと思いますか、それともミラーテーブルの方がよいと思いますか？

おそらく状況次第だと思いますが、同じ構造の2つのテーブルを持つという理想は好きではありません。わずかに遅い操作（データを表示するときに常にドラフトを照会する必要があるため）とのトレードオフは、それだけの価値がありますか？

私の会社には、構築した Web サイトにデプロイするアプリがいくつかあります。最近、非常に古いアプリを新しいアプリと一緒に含める必要があり、両方のアプリで使用する必要があるテーブル名が重複しているという競合がありました。

現在、古いアプリの更新を進めており、DB の更新がいくつかあります。これらの名前の競合が起こらないようにするために、人々がベスト プラクティスと見なすもの (またはその方法) に興味があります。

スキーマを調べましたが、それが正しい道であるかどうかはわかりません。ドキュメントで規定されているように、特定のスキーマ名をアプリケーションに「配線」したくありません。また、スキーマをユーザー検索パスに追加すると、2 つのスキーマが同じテーブル名を持っている場合、参照しているテーブルをどのように知ることができますか。とはいえ、多分私はこれについて多くのことを読んでいます。

洞察や知恵の言葉は大歓迎です！

サーバーからのデータを利用するアプリケーションを構築したいと考えており、アプリケーション内のデータを他のクライアント アプリケーションによって入力されたデータと同期する必要があります。それで、いくつかの質問があります：

• データベーススキーマを効率的に設計するには? サーバー上で同じデータベース スキーマを複製する必要がありますか、それともフィールドとエンティティをさらに追加する必要がありますか?
• 各アプリケーションの起動時、またはアプリケーションのアイドル状態の間、またはその他の何かで、データを同期するための戦略は何ですか...
• ユーザーがアプリケーション内で入力したデータと、別のクライアント アプリケーションによって入力されたデータの競合を処理する方法。

どんな反応でも大歓迎です。

典型的なMVCWebアプリケーションの場合、ルーター/ディスパッチャールーチンを使用して、主にユーザーがURLで要求した領域に基づいてロードするコントローラーを決定すると思います。

ただし、URLクエリ文字列をチェックするだけでなく、ディスパッチャーを使用して、ユーザーが現在ログインしているかどうかをチェックし、どのコントローラーがロードされているかを判断することも好きです。たとえば、ログインしてログインページを要求した場合、コーディネーターは代わりにアカウントをロードします。

しかし、これはかなり非標準的な設計ですか？何らかの形でMVCに違反しますか？今週末に読んだ例では、ディスパッチャールーチンの前に主要な計算が実行されていないため、通常、ユーザーがコントローラーごとにログインしているかどうかを確認し、必要に応じてリダイレクトします。

しかし、そもそもアカウントコントローラをロードできるのであれば、ログインしたユーザーをログインエリアからアカウントエリアにリダイレクトするのは奇妙に思えますか？

私の驚愕について十分に説明できたと思いますが、ログインしたユーザーの処理方法や同様のセッションデータについて、誰かが詳細を教えてくれませんか？

私はTDDを始めたばかりで、他の人がテストを実行するためにどのようなアプローチを取るのか興味があります。参考までに、私はグーグルのテストフレームワークを使用していますが、この質問は他のほとんどのテストフレームワークとC /C++以外の言語に当てはまると思います。

これまでの私の一般的なアプローチは、次の3つのいずれかを行うことでした。

1. アプリケーションの大部分を静的ライブラリに書き込んでから、2つの実行可能ファイルを作成します。1つの実行可能ファイルはアプリケーション自体であり、もう1つはすべてのテストを実行するテストランナーです。どちらも静的ライブラリにリンクしています。

2. テストコードをアプリケーション自体に直接埋め込み、コンパイラフラグを使用してテストコードを有効または無効にします。これはおそらく私がこれまで使用した中で最良のアプローチですが、コードが少し乱雑になります。

3. テストコードをアプリケーション自体に直接埋め込みます。特定のコマンドラインスイッチを指定すると、アプリケーション自体を実行するか、アプリケーションに埋め込まれたテストを実行します。

これらのソリューションはどれも特にエレガントではありません...

どうしますか？

中規模の Web アプリケーションの設計を開始しています。私は通常、トップダウンで設計するのが好きです。つまり、最高レベルから始めて、下に向かって設計します。次のレイヤーを計画しています。

• プレゼンテーション (PHP/Ajax)
• ビジネスの論理
• データアクセス
• データベース

ここで、各レイヤーの主要なオブジェクトとレイヤー間の相互作用のスケッチを開始したいと思います。Visio のようなグラフィックス/ダイアグラム ツールを使用するよりも、この目的に特化したツールはありますか?

最初に、私が現在行っているような詳細を説明するのにしばらく時間がかかったと言いたいです。最近、私は SharePoint の世界に深く関わっており、かなり長い間、思考プロセス全体がそこに集中していました。データベースを再び作成したり、データ アクセスを処理するための「下位レベル」のコードを作成したりできることを非常にうれしく思います。

私は非常に単純な Web アプリケーションに取り組んでおり、プロジェクトやさまざまなコード レイヤーを構成するために使用した方法を再確認する機会を得ています。たとえば、前回、基本的なものをゼロから構築しようとしたときに、次のようなものを作成した可能性があります。

それは、私が実際の作業を行ったプロジェクトであり、ASP.NET プロジェクトで参照されていました。当時、ASP.NET MVC はまだ非常に新しく、積極的に開発されていることがわかり、堅実な人々によって開発された唯一のオープン プロジェクトだったので、私のアプローチは CodeCampServer プロジェクトから見たものに非常に触発されました。

取り組んでいる一般的な問題に関して、プロジェクトとコードをどのように構築していますか? 確かにさまざまな問題がこれに制約を課す可能性がありますが、コードの構造とレイアウトに影響を与える特定のニーズのない基本的な問題であると想定してください。

複数のユーザーが (アプリケーションの異なるインスタンスを使用して) 同時に編集できる多数のカスタム オブジェクトを管理するアプリケーションを構築しています。これらのオブジェクトには基礎となるシリアル化された表現があり、私の計画は、それらを (アプリケーション UI を介して) 外部のソース管理システムに永続化することです。もちろん、これは、アプリケーションがオブジェクトの現在のバージョンの更新、各オブジェクトのマージ インターフェイスなどをチェックできることを意味します。

私の質問は、サポートするソース管理パラダイムと特定のソリューション、およびその理由です。私がソース管理の世界を (おそらく単純に) 見ている方法は、次の 3 つの一般的なパラダイムです。

1. 単一リポジトリ、ロックされたアクセス (MS SourceSafe)
2. 単一リポジトリ、同時アクセス (CVS/SVN)
3. 分散 (Mercurial、Git)

#1 を使用している人は何年も聞いていないので、このケースは完全に無視するつもりです (他に説得力のある議論が得られない限り)。ただし、#2 と #3 のどちらをサポートするか、具体的にどの実装をサポートするかについて、私は途方に暮れています。使用パラダイムが微妙に異なり、単一の UI で基本的な操作を適切に捉えることができないことを懸念しています。

最後にお伝えしておきたいのは、このアプリケーションは、ソース管理システムが既に使用されている可能性がある商用環境での展開を意図していることです。それが本当に契約を破るものでない限り、複数のソリューションをサポートしたくないので、企業環境で広く採用されることはプラスです.

更新：私は具体的にいくつかの理由を探しています：

1. 商業的に受け入れられているという理由で、どちらのパラダイムが理にかなっていますか? （これは@Andrew Colsonによって回答されたと思いますが、他の人の経験は異なる場合があります）
2. 平均的な商用開発ショップが、アプリケーション用に 2 つ目のソース管理システムを維持するよりも、既存のソース管理システムを利用することを好むというのは合理的な仮定でしょうか (私のアプリが通常の開発プロセスとは別の重要なニーズを満たすことを考えると)。
3. 私のニーズでは、これらのパラダイムの 1 つを歪めることなく、#2 と #3 を単一の一連の操作に合理的に取り込むことはできないと仮定して正しいでしょうか?
4. 私が使用すべきだと思うパラダイムについて、どの特定の実装をサポートすることが重要だと思いますか?

.NET でアプリケーション (クラス、クラス ライブラリのインターフェイス) をどのように設計しますか? 固定データベース設計があり、サード パーティのデータ ソースからのデータのインポートをサポートする必要がある場合、おそらく XML になりますか?

たとえば、ID タイトル 説明 税レベル 価格 の列を持つ製品テーブルが DB にあるとします。

反対側には、たとえば Products: ProductId ProdTitle Text BasicPrice Quantity があります。

現在、私は次のようにしています: サードパーティの XML をクラスと XSD に変換し、そのコンテンツを強い型指定されたオブジェクトに逆シリアル化します (このプロセスの結果として得られるのは、ThirdPartyProduct、ThirdPartyClassification などのクラスです)。

次に、次のような方法があります。

現時点ではインターフェイスを使用していませんが、使用したいと考えています。私が望むのは、次のようなものを実装することです

ここで、ProductSynchronization はインターフェイスまたは抽象クラスになります。ProductSynchronization の多くの実装がある可能性が高いです。型をハードコードすることはできません。ContosoProduct、NorthwindProduct などのクラスは、サード パーティの XML から作成される可能性があります (そのため、引き続き逆シリアル化を使用することをお勧めします)。

ここで私が説明しようとしていることを誰かが理解してくれることを願っています。あなたが販売者であり、多数のプロバイダーがあり、それぞれが独自の独自の XML 形式を使用していると想像してください。もちろん、新しいフォーマットが登場するたびに必要になる開発は気にしません.10〜20個のメソッドを実装する必要があるだけなので、アーキテクチャをオープンにしてそれをサポートしたいだけです.

返信では、データ アクセス テクノロジではなく、設計に重点を置いてください。ほとんどのテクノロジは非常に簡単に使用できるためです (知る必要がある場合は、EF をデータベースとの対話に使用します)。