タグ付けされた質問 「n-tier」

データベースはデータレイヤーに属しているのに対し、ストアドプロシージャはビジネスロジックであるため、データベース内のストアドプロシージャにビジネスロジックがあると、3層分離アーキテクチャに違反するという話を私の同僚から受けました。 ストアドプロシージャがなければ、世界は非常に厳しい場所になると思います。 彼らは本当に3層分離に違反していますか？

41 business-logic  n-tier  layers  stored-procedures  separation-of-concerns 

職場では、2年近く開発中の大規模な内部アプリケーションがあります。私は最近プロジェクトに参加しましたが、アーキテクチャの一部には少し困惑しているので、建築家に同じ質問をする前にここの誰かがアドバイスを提供できることを願っています）。 以下が少し長い場合は申し訳ありませんが、質問する前にシステムが何であるかをよく描きたいと思います:) システムのセットアップ方法は、1つのメインWebアプリケーション（asp.net、AngularJS）があり、ほとんどの場合、他のさまざまなサービスからのデータを集約するだけです。したがって、基本的には、AngularJSアプリケーションのホストです。文字通り、クライアント側をブートストラップする1つのMVCコントローラーがあり、他のすべてのコントローラーはWebAPIコントローラーです。 クライアント側からの呼び出しは、これらのコントローラーによって処理されます。これらのコントローラーは、Webアプリケーションをホストするだけのボックスに常に展開されます。現在、このようなボックスが4つあります。 ただし、呼び出しは最終的にさらに別のWebAPIアプリケーションのセットにルーティングされます（通常、これらはセキュリティ、顧客データ、製品データなどのビジネスエリアごとです）。これらのWebAPIはすべて、専用のボックスにも一緒にデプロイされます。また、これらのボックスが4つあります。 1つの例外を除き、これらのWebAPIは組織の他の部分では使用されません。 最後に、これらのWebAPIは「バックエンド」サービスをさらに別のセットで呼び出します。これは通常、さまざまなERPシステムおよびデータストア（制御不能）の上に置かれたレガシーasmxまたはwcfサービスです。 アプリケーションのビジネスロジックのほとんどは、これらのWebApiにあります。たとえば、レガシーデータの変換、集約、ビジネスルールの実行など、通常のタイプのものです。 私が混乱しているのは、WebApplicationと、それを提供するWebAPIをこのように分離することで得られる利点の可能性です。他の誰もそれらを使用していないため、スケーラビリティの利点はありません（つまり、APIサーバーの負荷の増加はWebサーバーの負荷の増加を意味するため、別の4つのAPIボックスを追加しても負荷はありません）したがって、WebサーバーとApiサーバーの比率は1：1でなければなりません） また、ブラウザ=> HTTP => WebApp => HTTP => WebAPI => HTTP =>バックエンドサービスを追加のHTTP呼び出しを行う必要があるという利点もまったくありません。（WebAppとWebAPI間のHTTP呼び出しが私の問題です） そのため、現在は、現在のWebAPIを個別のソリューションから、WebApplicationソリューション内の個別のプロジェクトに移動し、間に単純なプロジェクト参照と単一の展開モデルを配置することを検討しています。したがって、最終的にはクラスライブラリになります。 展開に関しては、これは4 + 4ではなく8つの「フルスタック」Webボックスがあることを意味します。 新しいアプローチのメリットは次のとおりです。 WebアプリケーションとWebAPIサーバー間のシリアル化/逆シリアル化のサイクルが1つ少ないため、パフォーマンスが向上します。 WebアプリケーションサーバーとWebApiサーバーのそれぞれの発信境界と着信境界のDTOとマッパーに関して削除できる（つまり、メンテナンス/テストする必要がない）大量のコード。 意味のある自動化された統合テストを作成する能力が向上しました。バックエンドサービスを単純​​にモックし、中間層のHTTPジャンプの混乱を回避できるからです。 だから質問は：私は間違っていますか？WebApplicationボックスとWebAPIボックスを分離したという基本的な「魔法」を見逃していませんか？ 私はいくつかのN-Tierアーキテクチャの資料を調査しましたが、状況に具体的な利益をもたらすことができるものを見つけることができないようです（スケーラビリティは私が知る限り問題ではなく、これは内部アプリなのでWebAPIアプリケーションに関するセキュリティは問題になりません。） また、システムを提案されたセットアップに再編成した場合、メリットの点で何が失われますか？

16 architecture  asp.net  enterprise-architecture  n-tier 

私は仕事でアプリケーションのデバッグを頻繁に行います。これは、テスト環境と実稼働環境を含む、ビジネスに展開するBIアプリケーションです。これらの制約に基づいて、人々が提案できるアプリ/ツール/メソッドがあるかどうか疑問に思っています： ソフトウェアはテスト環境がないカスタムサードパーティアプリケーションに依存しているため、クライアントサイトまたはローカルでデバッガーを使用することはできません。（編集：公平にするために、場合によってはローカルでデバッグすることができます。コアコード以外を使用しない場合、問題のあるコードの多くは、サードパーティ固有の通信をカプセル化するdllにあります：ソケット、プロセスパイプ、soap呼び出し、コアコードの動作を変更するカスタムロジック。通常、クライアントの実装または拡張中に、この領域に新しいコードを記述します。 アプリでは実質的にロギングは行われません。単体テストはありません。 バージョン管理には、フルソリューションの1つのバージョンしかありません（ソースセーフ2005を使用）。そのため、ソリューション全体の以前のバージョンを取得することはできず、個々のファイルのみを取得することができます。（誰かがこれを回避する方法を知っていない限り）。 ローカルでは再現できません。テスト環境では再現できないことがよくあります（テストと本番が同じバージョンではない可能性が高い）。 クライアントが使用しているバージョンがソースセーフのバージョンと異なる可能性が高くなります。これは、個々のファイルが更新され、その特定のクライアント用のカスタムロジックが埋め込まれているためです。多くの場合、バイナリが更新され、他のいくつかのバイナリを変更する必要がありますが、コミットが完了すると、これについての記録や知識はありません。よくあるエラーは、クライアント環境で「関数/メソッドが見つかりません」または「メソッド呼び出しに指定されたパラメーターが多すぎる/少なすぎる」ことです。 これは.net VBソリューションです クライアントサイトにはソフトウェアをインストールできませんが、ローカルにインストールできます 私たちのアプリケーションは非常にカスタマイズ可能ですが、残念ながら、カスタマイズロジックは、クライアントごとにデータベースに加えられたカスタム変更を含め、フロントエンドからデータレイヤーに至るすべてのクラスとファイルに分散されています。 コードには実質的にコメントはありません。アーキテクチャに関するドキュメントはありません。APIに関するドキュメントはありません。私たちが持っている唯一のものは、何が起こっているかをいくらか説明する何百もの電子メールチェーンです。コードを知っているのは元々コードを書いた人だけですが、彼らはもはや開発者ではないので、それほど関与しません。 そして、あなたがそれを言う前に...はい、私は知っています。自分も撃ちたいです。スパゲッティコード、何百ものコンパイラ警告、そして本当に修正すべきポリモーフィズムが存在することは助けにはなりませんが、私はそれに言及していません。 私が遭遇する最も一般的な種類のエラーは、null参照エラー、無効なキャスト、および欠落した関数/関数シグネチャの不一致です。幸運なことに、イベントビューアーはクラス、メソッド、例外メッセージをログに記録します。それは最も有用ではありませんが、それでも何かです。最悪なのは、スクリーンショット以外にトレースや再現手順がないエラーであり、上記のような一般的なエラーメッセージです。環境が適切に構成されておらず、それが後でなくなることを祈るだけで、それらが発生した理由を見つけることができない場合があります。 私はこれが少し暴言として出てくることを知っています、そしてある程度はそうです。しかし、私はオプションに必死です。私が使用できる他の方法/ツールはありますか？

16 .net  vb.net  n-tier 

現在、データアクセス戦略としてEntity Framework 5（.net 4）を使用しているn層ソリューションを設計していますが、依存性注入を組み込んでテスト可能/柔軟にする方法を検討しています。 私の現在のソリューションレイアウトは次のとおりです（私のソリューションはAlcatrazと呼ばれます）。 Alcatraz.WebUI：asp.net webformプロジェクト、フロントエンドユーザーインターフェイスは、プロジェクトAlcatraz.BusinessおよびAlcatraz.Data.Modelsを参照します。 Alcatraz.Business：クラスライブラリプロジェクト。ビジネスロジックを含み、プロジェクトAlcatraz.Data.Access、Alcatraz.Data.Modelsを参照します。 Alcatraz.Data.Access：クラスライブラリプロジェクトは、AlcatrazModel.edmxとAlcatrazEntitiesDbContextを収容し、プロジェクトAlcatraz.Data.Modelsを参照します。 Alcatraz.Data.Models：クラスライブラリプロジェクト。AlcatrazモデルのPOCOを含み、参照はありません。 このソリューションがどのように機能するかについての私のビジョンは、web-uiがビジネスライブラリ内のリポジトリをインスタンス化することです。このリポジトリは（コンストラクタを介して）接続文字列（AlcatrazEntitiesインスタンスではなく）の依存関係を持ちます。web-uiはデータベース接続文字列を知っていますが、それがエンティティフレームワーク接続文字列であることはわかりません。 ビジネスプロジェクトで： public class InmateRepository : IInmateRepository { private string _connectionString; public InmateRepository(string connectionString) { if (connectionString == null) { throw new ArgumentNullException("connectionString"); } EntityConnectionStringBuilder connectionBuilder = new EntityConnectionStringBuilder(); connectionBuilder.Metadata = "res://*/AlcatrazModel.csdl|res://*/AlcatrazModel.ssdl|res://*/AlcatrazModel.msl"; connectionBuilder.Provider = "System.Data.SqlClient"; connectionBuilder.ProviderConnectionString = connectionString; _connectionString = …

12 c#  .net  dependency-injection  entity-framework  n-tier 

BLがCRUDを実行するためにDAL（またはDALのインターフェース）のメソッドを呼び出す責任を負った3層アーキテクチャーよりも、オニオンアーキテクチャーにのみ利点があると思います。タマネギは、関心事、テスト容易性、保守容易性のより良い分離があり、よりきれいです。 だから、オニオンアーキテクチャはすべての面で本当に優れており、3層アーキテクチャは物事を行うための古い方法にすぎません。または、3層アーキテクチャを使用したい場合、いくつかのシナリオがあります。

11 design  architecture  layers  n-tier  onion-architecture 

中規模のMVC Webアプリケーションのアーキテクチャを計画するとき、レイヤーを可能な限り分離してテストしやすいように実装するにはどうすればよいですか？（基本的にベストプラクティスに従います）データアクセスとして最初にコードを使用しているとしましょう。 「ビジネスロジック」の定義、およびデータレイヤーとのやり取りをどのように定義するかについて、私は苦労しています。車両販売アプリケーションを例にとると、ビジネスロジックは、特定の車両の税帯の計算、ガロンあたりのマイル統計の比較などのタスクを実行するクラスでしょうか。ビジネスエンティティ（例：車、バン、オートバイ）については、これらをDataContextクラスと共にデータレイヤーに配置します。 また、ビジネスとは対照的に、アプリケーションロジックを構成するものは何ですか。セッション/ユーザー入力の検証などを推測していますか？ したがって、たとえば、車のコントローラは、タイプと最良のmpgでフィルタされた上位10台の車をリストするアクション/ビューの結果を返す場合があります。たとえば、ICarRepository「リポジトリ」/ DIを使用して「carRepo」をコントローラに注入したとします。アクションメソッドのパラメータから車をフィルタリングします。var cars = carRepo.getCarsByType("hatchback"); したがって、リポジトリを使用してデータアクセスの知識をコントローラーから除外し、ドメインモデルを使用してビジネスロジックをコントローラーから除外しました-var result = new MpgCalculator（cars）; -DBからエンティティをロード/フィルタリングするだけではなく、最高の燃料効率を計算するために追加のロジックを実行する必要があるため、電卓クラスが必要だとしましょう。これで、ビューをレンダリングするためのデータセットがあり、リポジトリを使用してデータアクセスレイヤーから取得し、ドメイン固有のオブジェクトを処理して、そのデータに対してビジネス関連のタスクを実行します。 ここで間違いをしていますか？それでもリポジトリパターンを使用する必要がありますか、それともORMを分離してテストするためにインターフェイスに対してコーディングするだけですか？このトピックでは、具体的なデータアクセスクラスdbcontextがデータレイヤーにあるので、インターフェイス定義をドメイン/ビジネスレイヤーに入れる必要があります。つまり、データアクセステクノロジーが変更されても、他のレイヤーは影響を受けません。 これまでに調べたことから、私の構造は次のようになります。 MVCインターネットアプリケーション ->標準インターネットプロジェクト-ここのモデルはViewModelsです ドメイン/ビジネスレイヤー ->コントローラーが関連するビューに渡す前にデータレイヤーからドメインエンティティを処理するために使用できるビジネス固有のクラス/モデル リポジトリの抽象化が必要ですか？->特にORMを使用する場合、これについて多くの議論が聞こえます データレイヤー ->エンティティクラス（Car、Van、Motorcycle）、DbContext-具象データアクセステクノロジーレイヤー

11 design-patterns  mvc  asp.net-mvc  repository  n-tier 

私が学んだ限り、にはIRepositoryが含まれている必要がありますCRUD。その後、我々はこれを継承するIRepositoryような当社の他のインターフェイスにIProductして実装するIProduct具象クラスをProductRepository、などの方法でGetAllProducts()、Top5Products()。 n層アーキテクチャでも同じことができます。作成、のようにDAL Class Library、そこにクラスを定義するProductような方法でGetAllProducts()、Top5Products()。 両方において、DAL.ProductそしてRepo.ProductRepository、我々は初期化したクラスDB ContextでEntity Framework、当社の関連データを照会します。 呼び出しは両方Repo.ProductRepositoryまたはDAL.Productメソッドから似ていますBLL これらの類似点を考慮して、私の質問はレポの利点は何ですか？私はn層アーキテクチャを使用して非常に簡単に同じことを行うことができます（Controller、BLL Class Library、DAL Class Library）。

9 design-patterns  architecture  repository  n-tier  repository-pattern 

人々は「3層（またはn層）アーキテクチャ」に従っているとしばしば主張し、時にはドメインモデルに切り替えると主張することもあります。しかし、私はこの神秘的な「3層アーキテクチャ」が何であるかを本当に理解したことがありません。正式な定義がないようです。ドメインモデルパターンを説明およびデモする参照や例は数多くありますが、3層への参照は、コードをUI、ビジネスロジック、およびデータアクセスレイヤーに分離することを示唆しています。そして、それは彼らが言うように見えるすべてです。 私が特に奇妙だと思うのは、ドメインモデルは、この3層のパラダイムを完璧に具現化したものだということです。ORMファイルとマッピングファイルはデータアクセスレイヤー、ドメインはビジネスロジック、UIはUIです。それではなぜ人々はそれが新しい何かであり、彼らが切り替えるべきものであるかのように話すのですか？ ドメインモデルを実装している人を見る前は、ほとんどのアプリケーションはUIであり、ロジックはUIとSPに分割されたストアドプロシージャにアクセスしていました。「UI」、「BLL」、「DLL」と呼ばれるいくつかのアセンブリが時々ありましたが、通常これらは単にUIとSP間のメディエーターであり、ロジックがランダムに分散するためのより多くの場所を残しました。 では、この神秘的な「3層」アーキテクチャとは何でしょうか。それは本当に存在していますか？もしそうなら、それがうまく実装されている例はどこにありますか？

8 architecture  domain-model  n-tier