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

NetBeansプラットフォーム7に基づくリッチデスクトップアプリケーションの「メイン」クラスを設計しようとしています。このアプリケーションはHTTPサービスを消費し、TCP上の「プッシュシステム」を通じてメッセージを受信します。 私たちは3人の開発者であり、モジュールを並行して開発したいと考えています アプリケーションは階層化されます（データ、ビジネス、プレゼンテーション） 責任を分離するために、プレゼンテーションモデルを使用します いくつかの詳細なデータ（Bean Personなど）は複数の画面で共有されます（同時に複数の画面に表示される可能性があります） ... 個別の画面を開発することはできますが、アプリケーション全体を整理し、各モジュールのコンテンツを定義する方法を正確には知りません。 それでは、アプリケーション全体の相互作用を調整/管理するためのアドバイス（パターン/ベストプラクティス/本/サンプルアプリ）はありますか？ モジュールのコンテンツを定義する方法について何かアドバイスはありますか？ ありがとう！ 私が構築したいものを説明する小さな例：Fooユーザー管理アプリケーション アプリケーションを起動します 左側の[エクスプローラ]にプラットフォームのリストがあります（リストはローカルファイルに保存されます） 上部には、新しいプラットフォームを追加するためのボタンがあります（右クリックでも利用可能） プラットフォームをダブルクリックすると、アプリはHTTPサービスを呼び出し、ユーザーの完全なリストを取得します。このリストは[エディタ]に表示されます（JTable内） バックグラウンドプロセスが開始されます：TCP接続を介してメッセージを受信します ツールバーのボタンのおかげで新しいユーザーを追加することが可能です アプリケーションが別のPCで起動され、ユーザーが同じプラットフォームに接続している場合、そのユーザーリストは動的に更新されます（追加/削除/ステータス：{オフライン/オンライン}）（メッセージのおかげで） 将来的にはチャットモジュールが提供される予定です。 私の質問は（言い換えれば）：各モジュールのコンテンツを決定するためのアドバイス/ベストプラクティスですか？PM（プレゼンテーションモデル）がビュー/ビジネスとデータを分離して画面を作成する良い方法である場合、PMに基づいて複数の画面をリンクする最良の方法は何ですか？チャットモジュールを開発し、ユーザーリストを右クリックして表示されるコンテキストメニューに「ディスカッション...」というエントリを追加する方法を想像してみてください。

10 java  swing  architecture 

次の機能を実装するwpfアプリケーションを構築しています。 ユーザー入力を取得し、データベースからデータを読み取る それにいくつかの計算を行います 複数のタイプのビューでユーザーにそれを紹介し、変更をデータベースに書き込みます 提案されたアーキテクチャ：データベース->エンティティフレームワーク->リポジトリ->ビジネスロジック->データサービス-> ViewModel このアーキテクチャを使用する理由：アプリケーション（複数のビュー）と複数のデータベースに存在する複数のシナリオ。したがって、私は抽象化のために真ん中にリポジトリを使用する用意があります。 注意点の1つは、リポジトリが実装されている場合、コンテキストは長期間有効であることです。これを克服するために、コンテキストを作成し、それらを各クラッドメソッドのusing（）ブロックに配置しても問題ありませんか？ 別のアプローチを提案すること自由に感じなさい。

10 c#  design  architecture  wpf 

私が学んだ限り、には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 

私はすべての長所と短所、いつ、なぜなどの高レベルの概要を取得しようとするマイクロサービスアーキテクチャを研究してきました。私が読んで/見ている情報の多くは、ThoughtWorks（Martin Fowler、Neal Fordなどからのものです） al）。 この問題に関するMartin Fowlerの仕事の大部分は数年前のものであり、Microservices（プログラミングの一般的な名称ではないが）がまだ若かったため、私はその多くを少しずつ理解しました。 特に、これは次のとおりです。 マイクロサービスアーキテクチャを使用するチームの話を聞いていると、共通のパターンに気づきました。 成功したマイクロサービスストーリーのほとんどすべては、大きくなりすぎて分割されたモノリスから始まりました。 最初からマイクロサービスシステムとして構築されたシステムについて聞いたほとんどすべての場合、それは深刻な問題に終わっています。 このパターンにより、多くの同僚は、アプリケーションが価値があるほど十分に大きいアプリケーションであっても、マイクロサービスで新しいプロジェクトを開始すべきではないと主張しました。。 （参照：https : //martinfowler.com/bliki/MonolithFirst.html-彼らを強調） さて、3年後、マイクロサービスがよりユビキタスな言葉になりましたが、新しいシステムは通常、最初により大きい（-microservice-but-smaller-than-monolith）サービスチャンクを用意し、それらは進化的測定の一部としてより細かく？ または、上記のステートメントとは対照的に、きめ細かなマイクロサービスアーキテクチャを使用してプロジェクトをゼロから開始する基準はありますか？ 正気な一般的なアプローチのようですが、コミュニティの考えに興味があります。

9 architecture  microservices 

私はアーキテクチャで作業しています。Webクライアントおよびモバイルアプリ用のREST APIを提供する予定です。私はSpring（spring mvc、spring data jpaなど）を使用しています。ドメインモデルは、JPA仕様でコーディングされています。 クリーンアーキテクチャのいくつかの概念を適用しようとしています（https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html）。すべてではありません。これは、jpaドメインモデルを維持するためです。 レイヤーを通過する実際の流れは次のとおりです。 フロントエンド <-> APIサービス -> サービス -> リポジトリ -> DB フロントエンド：Webクライアント、モバイルアプリ APIサービス：Rest Controllers、ここではコンバーターとdtoと呼び出しサービスを使用しています サービス：実装とインターフェースし、ビジネスロジックを含みます リポジトリ：CRUD操作とおそらくいくつかのSQLクエリを含む自動実装（Spring Data JPAによって実行）とのリポジトリインターフェイス 私の疑問：サービスとリポジトリの間に追加のレイヤーを使用する必要がありますか？ 私はこの新しいフローを計画しています： フロントエンド <-> APIサービス -> サービス -> 永続性 -> リポジトリ -> DB なぜこの永続化レイヤーを使用するのですか？クリーンアーキテクチャの記事で述べているように、不可知論的永続性レイヤーにアクセスするサービス実装（ビジネスロジックまたはユースケース）が欲しいです。また、リポジトリの使用を停止する場合など、別の「データアクセス」パターンを使用する場合は、変更は必要ありません。 class ProductServiceImpl implements ProductService { ProductRepository productRepository; void save(Product product) { // do …

9 architecture  persistence  services 

最新のプログラムで人気のある高レベルのアーキテクチャの選択は、RESTベースのマイクロサービスシステムです。これには、疎結合、再利用の容易さ、使用できるテクノロジーの制限の制限、高いスケーラビリティなどのいくつかの利点があります。 しかし、そのようなアーキテクチャーで私が予測する問題の1つは、アプリケーションの依存関係が何であるかについての可視性が低いことです。たとえば、1組のREST呼び出しを毎日使用するアプリケーションがあるとします。このアプリケーションは、REST呼び出しの2番目のセットも使用しますが、四半期に1回だけです。過去1週間のログをスキャンすると、1日のカロリーはすべて表示されますが、四半期ごとの呼び出しは表示されません。リファクタリングの時期になると、四半期ごとの呼び出しが中断するリスクが高くなります。 このリスクを軽減し、疎結合アーキテクチャの依存関係をより詳細に可視化するために使用できるパターンまたはツールは何ですか？

9 architecture  rest  enterprise-architecture  microservices  coupling 

現在、クラシックなn層アプリケーションがあります：DB / Webサービス/フロントエンド。他のコンポーネントがありますが、基本的なレイアウトです。 アプリケーションの可用性を改善する主な理由は3つあります。 私たちのホストは時々（すべてのように）停止を経験し、私たちは顧客への影響を最小限にしたいので、たとえば、データセンターAがダウンした場合、彼らはデータセンターBをオンにします。 バージョンをアップグレードすると、メンテナンスのためにサイトがシャットダウンされ、通常は数時間かかります（移行スクリプトなど）。ユーザーには、ダウンタイムを最小限に抑えて、よりシームレスな移行を望んでいます（サーバーAのアップグレード中にサーバーBを使用します）。 オプションとして、私たちの顧客は世界中にあり、私たちは彼らの接続が不安定である可能性があるにもかかわらず、可能な限り最高の体験をしてもらいたいと思っています（インドの開発者と一緒に働いた人は誰でも私が何を言っているか知っているはずです）。理想的には、私たちは彼らのオフィスにサーバーを接続できるようにしたい（または彼らの都市の近くのデータセンターを使用できる）ようにしたい、そしてそれは私たちのアーキテクチャにシームレスに統合するだろう。 リモートで99％の可用性を必要とせず、95％も必要としません。ドキュメント管理アプリです。誰も気にしない。ただし、移行には時間がかかる場合があり、世界中にお客様がいるため、お客様が1日のほとんどの時間にわたって仕事をすることができない場合があります。 SQLの部分については、「適切な」DBAがいない場合でも、SQLの可能性（レプリケーション、ミラーリングなど）について知っています。DB側では、このためのリソースを見つけるのは非常に簡単です。セッションやコードの保存など、他のすべてが難しいのは何ですか。Webサービスサーバーがダウンした場合、UIはそれを切り替える必要があることをどのように認識しますか？セッションはどのようにサーバー間で保持されますか？ 残念ながら、私たちの誰もこの分野での経験がなく、どこから探し始めればよいかさえわかりません。このためのベストプラクティスはありますか？デザインパターン？ライブラリー（お金がないため、無料で使用できます）？ ASP.NetとSQL Serverを使用しており、中央にWCF Webサービスがあります。Windowsサービスはたくさんありますが、ミッションクリティカルではありません。Webサイトを処理する方法がサービスに適用できると思います。 ほとんどのクラウドプラットフォームがこのための組み込みシステムを提供していることを理解していますが、私たちのシステム管理者はすべてを自分で管理し、誰にも依存しないことを望んでいるため、クラウドホスティングは不可能です。

9 architecture  architectural-patterns 

開発中のAndroidアプリでMVPパターンを使用しています。 基本的に4つの要素があります。 新しいユーザーを追加できるAddUserView： AddUserPresenter UserInfo（pojo） UserInfoManager（ビジネスロジックとストレージマネージャー） 私の質問は： AddUserViewの「追加」ボタンを押すと、テキストビューのコンテンツが取得され、新しいUserInfoがインスタンス化されて、Presenterに渡されます。または、AddUserViewは単にtextViewsのコンテンツを取得してAddUserPresenterに渡す必要があります。これにより、実際にはUserInfoがインスタンス化され、UserInfoManagerに渡されますか？

9 java  architecture  android  mvp 

私はイベントソーシングについて読んでいて、書き込みが非常にまれであるか、軍事レベルの監査が必要なエキゾチックな状況でのみ意味があるかどうかを自問するのをやめられません。 重要な使用法がある例外的ではないシステムでは、1日あたり数百から数千の書き込みが発生する可能性があり、たとえば、1年間の操作で100万回または2回の書き込み（つまりイベント）に変換されます。現在の状態を取得するためだけに数百万のオブジェクト（イベント）をマージすることは、従来のストレージからのまっすぐな読み取りと比較すると、ばかげた命題のように聞こえます。それでも、イベントソーシングは、最もパフォーマンスの高いシステムの背後にあります（LMAXなど）。 それで、私は何が欠けていますか？イベントストリームからの状態の復元は一般的に行われていますか？または、これを行う必要がほとんどなく、代わりに通常の操作（つまり、CQRSからのクエリストレージを使用）に別のストレージを使用し、例外的な場合（レプリケーション、監査など）にのみイベントから復元するという考えですか？

9 design-patterns  architecture  event-programming  architectural-patterns  event-sourcing 

私はこのウィキを安定した抽象化の原則（SAP）で読んでいました。 SAPは、パッケージの安定性が高いほど、抽象的である必要があると述べています。これは、パッケージの安定性が低い（変更される可能性が高い）場合、より具体的であることを意味します。私が本当に理解していないのは、これが事実であるべき理由です。確かにすべての場合において、安定性に関係なく、抽象化に依存し、具体的な実装を隠す必要がありますか？

9 design  design-patterns  architecture  object-oriented-design  design-principles 

環境 RESTアーキテクチャスタイルのステートレス性により、各リクエストは完全に独立しており、サーバーはクライアントに関する情報を決して保存しません。 したがって、どのクライアントがリソースのロックを取得するかをサーバーストアに要求するため、悲観的な同時実行制御は適していません。次に、Etagヘッダーを使用して、オプティミスティック並行性制御が使用されます。（ところで、私がそこに尋ねたように/programming/30080634/concurrency-in-a-rest-api） 問題 楽観的同時実行制御メカニズムの主な問題は、すべてのクライアントがいつでも任意の操作を実行できるようにすることです。 そして、RESTの無国籍原則を破ることなく、それを回避したいと思います。つまり、すべてのクライアントがいつでも操作を実行することはできません。 質問 私の考えでは、次のような準楽観的同時実行制御メカニズムで可能です。 クライアントはトークンを要求できます 生成できるトークンは1つだけで、有効期間は限られています リソース（POSTやPUTなど）で操作を実行するには、クライアントはこのトークンをリクエストの本文（またはヘッダー？）の一部として渡す必要があります。トークンを持たないクライアントは、これらの操作を実行できません。 これは、楽観的同時実行制御に非常に似ていますが、「すべてのクライアントがすべての操作を実行できる」とは逆に、1つのクライアントのみが一部の操作（トークンを取得したクライアント）を実行できる点が異なります。 このメカニズムはRESTアーキテクチャスタイルと互換性がありますか？それはその制約のいずれかを破りますか？私はSOについて質問することを考えていましたが、これはソフトウェア設計に関連する、よりハイレベルな質問のようです。

9 design  architecture  rest  concurrency 

これらのとりとめのない質問で私の質問が明確になることを願っています。ただし、そうでない場合は完全に理解できます。その場合はその旨をお知らせください。さらに明確にしていきます。 オブジェクト指向のゲーム開発に精通するために私が作成した非常に単純なゲームであるBoxPongに出会ってください。ボックスをドラッグしてボールを操作し、黄色い物を集めます。 BoxPongを作成することは、とりわけ、基本的な質問の策定に役立ちました。互いに「所属する」必要なしに、互いに対話するオブジェクトをどのようにして持つことができますか？言い換えれば、オブジェクトが階層的ではなく、代わりに共存する方法はありますか？（以下でさらに詳しく説明します。） オブジェクトの共存の問題はよくある問題だと思うので、解決する確立された方法があるといいのですが。私は四角いホイールを作り直したくないので、私が探している理想的な答えは「ここに、あなたの種類の問題を解決するために一般的に使用される設計パターンがある」と思います。 特にBoxPongのような単純なゲームでは、同じレベルで少数のオブジェクトが共存している、または共存している必要があることは明らかです。箱があり、ボールがあり、収集品があります。オブジェクト指向言語で表現できるのは、厳密なHAS-A関係だけですが、そうです。これは、メンバー変数を介して行われます。私は単に始めてballそれを実行させるだけではなく、永久に別のオブジェクトに属している必要があります。メインのゲームオブジェクトは、そのので、私はそれを設定した持っているボックスを、ひいてはボックスがありたボールを、そして持っているスコアカウンターを。各オブジェクトには、update()位置、方向などを計算するメソッドと同じように移動します。メインのゲームオブジェクトのupdateメソッドを呼び出します。このメソッドは、すべての子のupdateメソッドを呼び出し、次に、すべての子のupdateメソッドを呼び出します。これがオブジェクト指向のゲームを作るために私が見ることができる唯一の方法ですが、それは理想的な方法ではないと感じています。結局のところ、私はボールをボックスに属していると正確に考えるのではなく、同じレベルにいて、それと相互作用していると考えています。これは、すべてのゲームオブジェクトをメインゲームオブジェクトのメンバー変数に変換することで実現できると思いますが、何も解決しないと思います。つまり...明らかな混乱をさけて、ボールとボックスがどのようにしてがお互い知る、つまり相互作用か？ また、オブジェクト間で情報を渡す必要があるという問題もあります。私はSNESのコードを書くのにかなりの経験があります。そこでは、実質的に常にRAM全体にアクセスできます。スーパーマリオワールドのカスタム敵を作成していて、マリオのコインをすべて削除して、ゼロを格納して$ 0DBFに対処したいとします。問題ありません。敵がプレイヤーのステータスにアクセスできないという制限はありません。C ++などでは、他のオブジェクト（またはグローバル）から値にアクセスできるようにする方法に疑問を感じることが多いので、私はこの自由に甘やかされていると思います。 BoxPongの例を使用して、ボールが画面の端から跳ね返るようにしたい場合はどうなりますか？widthそして、heightのプロパティであるGameクラスは、ballそれらにアクセスできるようにします。これらの種類の値を（コンストラクターまたは必要なメソッドを介して）渡すこともできますが、それは私にとって悪い習慣であるだけです。 私の主な問題は、お互いを知るためにオブジェクトが必要であるということですが、それを行うために私が見ることができる唯一の方法は、厳密な階層であり、これは醜く非実用的です。 私はC ++の「友達クラス」について聞いたことがありますが、それらがどのように機能するかは知っていますが、それらが最終的な解決策である場合、どうして表示されないのですか friendすべてのC ++プロジェクト全体にキーワードが注がれて概念はすべてのOOP言語に存在するわけではありませんか？（私が最近学んだばかりの関数ポインターについても同じことが言えます。） あらゆる種類の回答を事前にありがとう—そして、あなたに意味をなさない部分があれば、私に知らせてください。

9 design-patterns  object-oriented  c++  architecture 

2つの既存のデータウェアハウスへのアクセスを抽象化する必要があるビジネスインテリジェンスプロジェクトに着手しています。セルフサービスのビジネスインテリジェンスがデータを結合し、2つの既存の倉庫の単一のビューを提供できるように、アプリケーションアーキテクチャを設計する必要があります。私はこのようなものを考え出しました： 私は仮想化/キャッシングの部分に苦労しており、私の問題を解決するためのエンタープライズ設計パターンがあるかどうか疑問に思っています。このようなアーキテクチャは、データウェアハウスのスタースキーマを抽象化するのに役立ちますか？Red Hat JBoss Data VirtualizationやRed Hat JBoss Data Gridなどの製品を探しています。 現在Hibernateを使用しておらず、データグリッドについての私の理解は、それらがキー値ストアまたはオブジェクトストアであるため、リレーショナルモデルのキャッシュには適していません。また、セルフサービスダッシュボードパーツにはベンダー製品を使用したいと考えていますが、ベンダーが必要なすべてを提供できない場合は、この領域でカスタムビルドを実行する可能性があります。

9 architecture  caching 

この質問を投稿する前に、いくつか調査を行いました。他の質問や投稿の中で、そのうちの1つを以下に示します。どのように判断するか明確な心がつかめなかった。 データアクセス層内のビジネスオブジェクト リポジトリがあり、ビジネスレイヤーはリポジトリを呼び出してデータを取得します。たとえば、BLLとDALの次のクラスがあるとします。 class BllCustomer { public int CustomerId {get; set;} public String Name {get; set;} public BllAddress Address {get; set;} } class BllAddress { public int AddressId {get; set;} public String Street {get; set;} public String City {get; set;} public String ZipCode {get; set; } } class DalCustomer { …

9 c#  architecture  .net  database  business-logic 

私は、各実装がユーザーインターフェイスの一部をカスタマイズできるようにするアプリケーションフレームワークの設計を任されています。そのような例の1つは、実装（これをクライアントと呼びましょう）が、特定の画面に返すコレクションビューセルを定義できることです。フレームワークは、適切なオブジェクトを販売してアプリを簡単に構築できるようにするだけです。これは、いくつかの類似したインスタンスを構築するためです。 フレームワークへの私の現在のアプローチは、アプリ全体のすべてのプレゼンテーションおよび却下イベントを担当する調整コントローラーを設計することでした。デフォルトのCoordination Controllerは、フレームワーク内のすべてのデフォルトのビューコントローラーを提供します。デフォルトのビューコントローラーは、構成されたUIを提供することなく、関連するタスクをすべて実行します。たとえば、1つのコントローラーがテンプレートセルを含むコレクションビューを表示し、特別なものは何もありません。この設計の利点は、コントローラー間の結合がなくなり、クライアントがデフォルトのコーディネーターをオーバーライドして、特定のタスクに対してまったく新しいビューコントローラーを返すことができることです。 私が抱えている問題は、このフレームワークを設計して、クライアントが独自のカスタムUIをアプリに追加できるようにする方法です。 アプローチ1 フレームワークにビューファクトリを必要とし、このビューファクトリがすべての関連するビューの販売を担当するようにします。したがって、アプリデリゲートでは、クライアントがたとえばCollectionViewCellFactoryを作成し、インターフェイスが、準拠するクラスが提供する必要のあるすべてのセルを定義するように強制できます。私はこのデザインのコードベースを継承しましたが、コードベースが抽象化されすぎてカスタマイズできなかったので、コードベースから離れました。これには、アプリのあらゆる側面に対応する多数のファクトリーが付属しており、これにより、すべてのアプリのセットアップ時間に数日が追加されました。 アプローチ2 各ビューコントローラーは、これらのカスタムUIクラスを実行時に定義できるようにするサブクラス化フックまたはセットアップAPIを指定します（UISplitViewControllerが呼び出し側がviewControllersプロパティを使用してコントローラーをセットアップする方法と同様です）。これを行うには、各クライアントは基本の調整コントローラーと各コントローラープレゼンテーションでサブクラス化するだけです。コントローラに適切な値を設定して、目的のUIを実現します。何かのようなもの viewController.registerReusableCellsBlock = ^(UICollectionView *collectionView){ //perform custom registration } viewController.cellDequeueBlock = ^UICollectionViewCell<SomeProtocol> *(UICollectionView *collectionView,NSIndexPath *indexPath){ //dequeue custom cells } 現在、私は再利用性を促進し、ViewControllerの肥大化を防ぐために、ビューのデータソースを別のオブジェクトに分離しています。これにより、セルのインターフェイスを提供するビューコントローラーのサブクラス化が少し難しくなりますが、不可能ではありません。 アプローチ3 おそらく、フレームワークを設計してその使用法を予測しようとするのは悪い考えです。おそらく、最良のオプションは、セットアップコストが比較的高い場合でも、最大限の制御でサブクラス化できるようにすることです。次に、いくつかのクライアント用に構築したら、出現するパターンに気づき、ルートに沿って最適化を開始します。 私はフレームワークの内部でカスタマイズ可能にする方法を理解しています。私が苦労しているのは、クライアントによるフレームワークの潜在的なカスタマイズポイントを定義するインターフェースを最適に定義する方法です。 TL; DR インターフェイスの最も複雑な部分は、コレクションビューセル内にネストされたコレクションビューを扱います。これにより、セルの水平ページングと垂直スクロールが可能になります。これは、水平セルを管理し、各セルのコレクションビューを新しいデータソースで構成する1つのデータソースを持つことで実現されます。 これらすべてのセルをカスタマイズ可能にするインターフェイスをどのように設計しますか？

9 design  architecture  ios  user-interface