問題タブ [n-tier-architecture]

クライアント向けの給与計算システムを設計しています。

私たちが対象としている組織は、次のような階層を持っています: 会社 -> クラスター -> ビジネス ユニット (BU) -> 部門 -> 従業員

従業員の給与は、さまざまな給与コンポーネントで構成されています。各給与コンポーネントには、それに関連付けられた 3 つのルール、計算ルール (コンポーネントを別のコンポーネントの %、または固定数または固定数の % として計算)、適格性ルール (従業員/部門がコンポーネントに対して適格であるかどうか)、およびコンポーネントの最大値と最小値を制限する制約ルール。

****これらのルールは編集可能であり、ユーザー エンド ユーザーが編集できます**。また、これらのルールはトップダウンで継承されますが、下位レベルで定義されている場合は、下位レベルのルールが優先されます。**

出席、休暇、ボーナスのテーブルを持つデータベースがあり、これらのルールもこれらのテーブルとやり取りすることになっています。

クライアントは、それぞれ個別のデータベース インスタンスをホストする複数のクライアントの給与を生成します。それらはそれぞれ、各コンポーネントの異なる解釈を持っている可能性があり、異なるコンポーネントを持っている可能性があります。

SQL Server のサポートのみを検討しており、給与計算はオフライン アクティビティになります。

これらのルールを使用して個々の税コンポーネント (税額控除、税控除、手当などを含む) を生成するロジックをどこに配置するかについては、意見が分かれています。

一部の人々は、従業員 ID を取得してその月の給与を生成する魔法の SP を提唱しています。他の人は、アプリケーション層で従業員の依存データを取得し、そこでこれらのコンポーネントを計算する個別のコンポーネントにロジックを分割することを望んでいます。

優先順位は次のとおりです。 1. 新しいクライアントに変更を迅速に適応させる能力 2. 長期的な保守性 3. パフォーマンス

これはオフラインのアクティビティであるため、1 と 2 は 3 を大幅に上回ります。

保守性と迅速なカスタマイズ性は非常に重要です。さまざまなクライアントにアプリケーションを展開します。クライアント A は ((0.3 * Basic) + 800) の給与コンポーネント ルールを持ち、クライアント B は (0.2 * Basic) + (0.1 * 出席ボーナス) のように定義します。

上記のルールはエンド ユーザーによって指定され、Web UI を介してカスタマイズ可能である必要があるため、SP はここで混乱を引き起こします。SQL から数式を解析する必要があります。それはどのくらい難しいですか、それとも簡単ですか？アプリケーション層 (C# .Net) でこれを行うと、SP を使用する場合よりもどのような利点がありますか?

元の投稿は次のとおりです: デザインのヒント、給与システム...再投稿 ...しかし、適切に回答された質問はありませんでした。

既存のシステムのアーキテクチャへの提案とポインタは非常に役立ちます。...そして、はい、システムの他の場所で LINQ to SQL を使用しています。

敬具、アシッシュ・シャルマ

私は、DAO を使用する独学の vb6 プログラマーです。以下は、私が作成できる典型的なコードの例です。

上記は CRUD アプリケーションのソース コード全体であると想定してください。このデザインが悪いことはわかっています。すべてがごちゃ混ぜになっています。理想的には、ユーザー インターフェイス、ビジネス ロジック、およびデータ アクセスという 3 つの異なるレイヤーが必要です。これが望ましい理由はなんとなくわかりますが、それがどのように行われるのかはわかりません。そのため、そのような分離が良い理由を完全には理解していないのではないかと思います. 誰かが上記のばかばかしいほど些細な例を 3 層にリファクタリングできれば、私はずっと先のことになると思います。

編集: SqlDataAdapters を使用してデータセットを埋めています。申し訳ありませんが、もっと明確にする必要がありました。

私は、厳密に型指定された多数のデータ セットにストアド プロシージャからの情報を入力する必要があるプロジェクトに取り組んでいます。現在、データ アクセス レイヤーにジェネリック メソッドがあります。

これに関する問題は、ストアド プロシージャから返されたレコードセットとデータ セット内のテーブルとの間のマッピングを確立する必要があることです。これを行うための 2 つのオプションを考え出しました。

• テーブル マッピングの情報を提供する新しい形式をFillDataSetメソッド ( )に追加します。KeyValuePair<string, string>[] mappings
• パラメータとして DataSet を受け取る を作成し、DataSetMappingFactoryそのタイプに基づいて適切なマッピングを追加します。不明なタイプの場合、マッピングは追加されません。DataSet次に、FillDataSetメソッドに を返します。

この問題にどのように取り組むことができるかについて、他に考えている人はいますか? また、オブジェクト指向設計の観点から最適なアプローチについて検討したい人はいますか?

私のアプローチが大丈夫かどうか、または改善できるかどうか疑問に思っています:

このようなオブジェクト マッピングを持つことについての考えはありますか?

トランザクションが入力され、ワー​​クフローを通過する Web サイトがあります。階層化されたアプリケーションでは、標準の BLL (ビジネス ロジック レイヤー)、DTO (データ転送オブジェクト)、DAL (データ アクセス レイヤー) などに従います。一部のトランザクションは、異なるビジネス ロジックを持つ複数のアプリケーションにまたがるため、すべてを分離する必要があります。

バックエンド プロセッサもあります。ワークフローが完了すると、トランザクションが処理されます。さまざまなサードパーティのシステムで動作し、その一部は不安定であるか、それらへのインターフェースが不安定であり、トランザクションのステータスを報告します。各 Web サイトには、独自のバージョンのバックエンド プロセッサがあります。

さて、問題は、N 層を使用して、アプリケーションごとに新しい BLL を提案することです。上記のアプリケーションのレイアウトでは、バックエンド プロセッサと Web サイトは、連携して動作する 1 つのアプリケーション、または異なるビジネス ロジックを持つ 2 つのアプリケーションであると言えます。これを処理する理想的な方法は何ですか？1 つまたは 2 つのシステムのように動作しますか?

依存関係が混在する複数の Web サイト、デスクトップ アプリケーション、Web サービス、およびデータベースで構成される n 層システムの開発と展開をどのように管理しますか?

ソース管理と自動ビルドを備えた継続的統合環境があるとします。

最近、「N 層アーキテクチャの経験が必要」または「N 層アプリを開発できなければならない」というような文章を含む開発者の求人情報をかなりの数見ました。

このことから、N 層アーキテクチャとは何かという疑問が生じます。どうやって経験を積むのですか？

一元化されたデータおよびファイル ストレージ システム（ドキュメント イメージング用）を必要とする環境に Delphi アプリを展開する必要がありますが、相互接続が比較的貧弱な複数のブランチ オフィスがあります。3 層データベース アプリケーションが最善の方法であると考えているため、比較的軽量なデータ転送のニーズでリッチなデスクトップ エクスペリエンスを提供できます。ここまで、Delphi Datasnap、kbmMW、および Remobjects SDK について簡単に説明してきました。kbmMW と Remobjects SDK が使用する帯域幅が最も少ないようです。かなりの数のユーザー (700 以上をサポートする必要があります) が存在する困難な環境で、これらのテクノロジのいずれかを展開した経験がある人はいますか? ありがとう！

私たちは、内部クライアント システムが基盤となるデータ ストアのレコードを作成、更新、クエリできるようにする新しい中間層サービスに着手しています。このサービスは、最大 3 つの個別の基礎となるデータストアを集約します。この質問の目的のために、次のことを前提とします。

データ ストア #1: 独自の XML データベース。
データ ストア #2: 既製のリレーショナル データベース。
データ ストア #3: フラット ファイル ストア (バイナリとして格納されたファイル)。

クライアントは、クエリ/更新しているデータストアを知りません (または気にしません)。新しいサービスがその決定を下します。私の質問は次のとおりです。私の API は XML またはオブジェクトを公開する必要がありますか? たとえば、新しい API には add メソッドがあります。システムが自動車保管システムであると仮定すると、API の add メソッドは次のようになります。

または、次のようになります。

これで、2 番目のメソッドの入力時の型指定が弱くても、XML は少なくともスキーマに対してすぐに検証されます。

新しいサービスは C# で記述される予定です (バージョンはまだ決まっていませんが、おそらく WCF では 3/3.5 です)。API のクライアントは、C#/VBA/VB.Net/C++/Java である可能性があります。

詳細を教えてください。ありがとう

更新: API は、メッセージ バスを介して XML も発行することに注意してください。たとえば、新しい車が追加されると、車の XML が公開され、新しい車に関心のある人に通知されます。