タグ付けされた質問 「layers」

状況 今晩、私はStackOverflowに関する質問に回答しました。 質問： 既存のオブジェクトの編集は、リポジトリレイヤーまたはサービスで行う必要がありますか？ たとえば、借金のあるユーザーがいる場合。彼の借金を変えたい。UserRepositoryで実行するか、たとえば、BingingServiceなどのサービスでオブジェクトを取得して編集し、保存する必要がありますか？ 私の答え： オブジェクトを同じオブジェクトに変更する責任を負い、リポジトリを使用してこのオブジェクトを取得する必要があります。 状況の例： class User { private int debt; // debt in cents private string name; // getters public void makePayment(int cents){ debt -= cents; } } class UserRepository { public User GetUserByName(string name){ // Get appropriate user from database } } 私が受け取ったコメント： ビジネスロジックは実際にはサービス内にある必要があります。モデルではありません。 インターネットは何と言っていますか？ …

397 design-patterns  layers 

典型的な（適切に設計された）MVC Webアプリでは、データベースはモデルコードを認識せず、モデルコードはコントローラーコードを認識せず、コントローラーコードはビューコードを認識しません。（ハードウェアと同じくらい、あるいはそれ以上のレベルで開始することもでき、パターンも同じになると思います。） 別の方向に進むと、1つ下のレイヤーに移動できます。ビューはコントローラーを認識できますが、モデルは認識できません。コントローラーはモデルを認識できますが、データベースは認識できません。モデルはデータベースを認識できますが、OSは認識できません。（より深いものはおそらく無関係です。） なぜこれが良いアイデアなのか直感的に把握できますが、明確に説明することはできません。なぜこの単方向スタイルのレイヤー化が良いアイデアなのでしょうか？

66 architecture  mvc  encapsulation  layers 

バックグラウンド ： 私はAndroidアプリでボブおじさんのクリーンアーキテクチャを使用しようとしています。私はそれを行う正しい方法を示しようとしている多くのオープンソースプロジェクトを研究し、RxAndroidに基づいた興味深い実装を見つけました。 気づいたこと： すべてのレイヤー（プレゼンテーション、ドメイン、およびデータ）には、同じエンティティ（UMLを話す）のモデルクラスがあります。さらに、データが境界を越えたとき（レイヤーから別のレイヤーへ）にオブジェクトを変換するマッパークラスがあります。 質問 ： すべてのCRUD操作が必要な場合、すべてのモデルクラスが同じ属性で終わることがわかっている場合、すべてのレイヤーにモデルクラスが必要です。または、クリーンアーキテクチャを使用する場合のルールまたはベストプラクティスですか？

44 java  architecture  android  clean-code  layers 

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

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

Android開発でORMを使用するのは理にかなっていますか、それともUIとDBレイヤー間のより緊密な結合のためにフレームワークが最適化されていますか？ 背景：Androidの開発を始めたばかりで、最初の本能（.netの背景から来た）は、小さなオブジェクトリレーショナルマッパーや、ボイラープレートの負荷を減らすのに役立つ他のツール（POJO + OrmLite + Lombokなど）を探すことでした。 しかし、最初のおもちゃのアプリケーションを開発しているときに、データベースカーソルを明示的に必要とするUIクラスを見つけましたAlphabetIndexer。AndroidライブラリがUIとDBレイヤーの厳密な分離に適していないのではないかと疑問に思い、どこでもPOJOを使用しようとすると（データベースへの直接アクセスの代わりに）便利で時間を節約できる多くの機能を見逃してしまいます）。 明確化：ORM を一般的に使用する利点を非常によく知っています。AndroidクラスライブラリがORM と共にどの程度うまく機能するかに特に興味があります。

27 android  orm  layers  android-development 

アプリケーションの設計と開発の傾向は、「ガッツ」から始まっているようです。ドメイン、データアクセス、インフラストラクチャなどです。通常、GUIはプロセスの後半に来るようです。最初にGUIを構築するのが役に立つのではないかと思います... 私の理論的根拠は、少なくともプロトタイプGUIを構築することで、舞台裏で何が起こる必要があるかをよりよく理解できるため、ドメインとサポートコードで作業を開始するためのより良い位置にいるということです。 サポートコードがまだ記述されていない場合、GUIレイヤーが実際に行うことはあまりないという点で、このプラクティスの問題を見ることができます。おそらく、モックオブジェクトまたはスローアウェイクラス（ユニットテストで行われているようなもの）を構築すると、最初にGUIを構築するのに十分な基盤が提供されます。 これは実際のプロジェクトにとって実行可能なアイデアかもしれませんか？GDD（GUI Driven Development）を頭字語stableに追加できるかもしれません...

17 gui  application-design  layers 

「検証が階層化アーキテクチャのどこに属しているのかを尋ねる別の質問ではありませんか？！？」ええ、はい、しかし、これがこの問題に対する少し異なる見解になることを願っています。 私は、検証は多くの形式を取り、コンテキストベースであり、アーキテクチャの各レベルで異なると固く信じています。これが投稿の基礎です。各レイヤーで実行される検証のタイプを識別するのに役立ちます。また、よくある質問は、承認チェックの場所です。 サンプルシナリオは、ケータリングビジネスのアプリケーションからのものです。日中定期的に、運転手は、トラックを現場から現場へ移動する間に蓄積した余分な現金をオフィスに引き入れることができます。このアプリケーションでは、ユーザーはドライバーのIDと金額を収集することにより、「キャッシュドロップ」を記録できます。関連するレイヤーを説明するスケルトンコードを次に示します。 public class CashDropApi // This is in the Service Facade Layer { [WebInvoke(Method = "POST")] public void AddCashDrop(NewCashDropContract contract) { // 1 Service.AddCashDrop(contract.Amount, contract.DriverId); } } public class CashDropService // This is the Application Service in the Domain Layer { public void AddCashDrop(Decimal amount, Int32 driverId) { …

13 domain-driven-design  validation  layers 

n層アーキテクチャと依存性注入を備えた中規模のソフトウェアを考えると、ある層に属するオブジェクトは下位層のオブジェクトに依存することができますが、上位層のオブジェクトには決して依存しないと言えます。 しかし、同じレイヤーの他のオブジェクトに依存するオブジェクトについてどう考えるべきかわかりません。 例として、3つのレイヤーと画像内のオブジェクトのような複数のオブジェクトを持つアプリケーションを想定してみましょう。明らかに、トップダウンの依存関係（緑の矢印）は問題ありませんが、ボトムアップ（赤い矢印）は問題ありませんが、同じレイヤー内の依存関係（黄色の矢印）はどうでしょうか。 循環依存関係を除き、発生する可能性のある他の問題と、この場合に階層化アーキテクチャがどれだけ違反されているかについて興味があります。

12 architecture  dependencies  layers 

Entity Frameworkを少し使用しようとしていますが、レイヤーの分離に関する質問がありました。 私は通常UI-> BLL-> DALアプローチを使用しますが、ここでEFを使用する方法を知りたいです。 私のDALは通常、次のようなものです GetPerson(id) { // some sql return new Person(...) } BLL： GetPerson(id) { Return personDL.GetPerson(id) } UI： Person p = personBL.GetPerson(id) 私の質問は、EFが私のモデルとDALを作成するので、EFを自分のDAL内にラップするのは良い考えですか、それとも時間の無駄ですか？ EFをラップする必要がない場合でも、Model.esmxを独自のクラスライブラリ内に配置しますか、それともBLL内に配置してそこで作業するだけでいいでしょうか？ EFを自分のDAL内にラップする理由は実際にはわかりませんが、他の人が何をしているのか知りたいです。 したがって、上記の代わりに、DALを除外して、次のようにします。 BLL： GetPerson(id) { using (TestEntities context = new TestEntities()) { var result = from p in context.Persons.Where(p => p.Id = …

12 c#  entity-framework  layers 

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

11 design  architecture  layers  n-tier  onion-architecture 

ドメインドリブンデザインのプレゼンテーションレイヤーとアプリケーションレイヤーの間に明確な線を引くことができません。 コントローラ、ビュー、レイアウト、JavaScript、CSSファイルはどこに配置すればよいですか？ アプリケーション層かプレゼンテーション層か？ そして、それらが同じレイヤーですべて一緒に行く場合、何が他のレイヤーを含みますか？空っぽですか？

9 architecture  domain-driven-design  layers 

私はアプリケーションレイヤーについて読んでおり、次のプロジェクト（c＃、. Net）でこのデザインを使用したいと考えています。いくつかの質問： レイヤーの分離は名前空間を通じて行われますか？Project.BLL.Whatever、Project.DAL.Whatever レイヤー、コンポーネント（Project.BLL.Component1）、またはコンポーネント、レイヤー（Project.Component1.BLL）で分離する方が適切ですか？ 私のDALの場合、このレイヤーはさまざまなクラスを使用してさらに編成されますか？すべてのデータベース呼び出しが単一のクラスに入れられる場合、組織はありません。これらを異なるクラスまたは名前空間に分割する方が良いでしょうか？ DALクラスは通常静的ですか？毎回そのメソッドの1つを呼び出す前にDALオブジェクトをインスタンス化するのは面倒です。 これらのレイヤーで正しい方法で物事を行うためのその他のヒントをいただければ幸いです。

9 c#  code-organization  layers 

私が取り組んでいるプロジェクトの依存関係の一部として、いくつかのコアサービスを使用しています。私たちが大きな変更を加えることができないこれらのサービスは、大きな混乱です。呼び出すメソッドに応じて、パラメーター（および戻り値）を別のエンコーディング、ロケール、タイムゾーンに変換する必要があります。 これらのパラメーターは独自のコードの複数の場所で生成されるため、これらの変換は複数の場所で実行されます。私たちがそれらを私たちの側に渡す前に、それらを生成するときがあります。コアサービスでメソッドを呼び出す直前。混乱がコード全体に広がっているので、それを分離するためのレイヤーを導入したいと思います。 私の質問は、そのための最良のアプローチは何ですか。最初は、使用する必要がある各サービス/メソッドに対応するサービス/メソッドを作成することを考えました。これらのメソッドは、単に変換を実行し、コアサービスに委任し、戻り値の変換を実行します。しかし、これはどういうわけか扱いにくいようです。 その後、アノテーションを使用することを考えましたが、使用方法は完全にはわかりません。そして、私が理解しているように、理想的には、呼び出されたメソッドに注釈を付ける必要があります。たとえば、パラメーターを@converToUtcで注釈し、注釈の実装で変換を行うことができます。これは正しいです？もちろん、これは私たちのコードではなく、現在私たち以外のプロジェクトでこれらのメソッドを使用しているコードを壊すので、これは難しいことです。 この状況に最適なアプローチは何ですか？

8 java  clean-code  layers