タグ付けされた質問 「architectural-patterns」

JWT仕様では、ペイロードとその送信方法のみが記述されていますが、認証プロトコルは開いたままになっているため、柔軟性が得られますが、残念ながら柔軟性により、アンチパターンや設計ミスが発生する可能性があります。 私はJWT認証のためによく考えテストされたエンタープライズパターンを探しています。これは使用または適応できますが、完全なものを見つけることができませんでした。 私が考えていたのは： Authorizationヘッダーが満たされていない場合、またはJWTトークンが無効であるか、期限切れの場合は、HTTP 401を送信します。 認証するには、/ login RESTチャネルを使用し、JSONオブジェクトとしてユーザー名とパスワードを送信します トークンを存続させるには、/ keepalive RESTチャネルを使用し、N（5）分ごとに呼び出し、新しいJWTトークンを受け取り、呼び出しごとに既存のトークンを置き換えます（トークンはM（15）分後に期限切れになります）。 ただし、私を邪魔するのは、その/ keepaliveチャネルの必要性です。一方、ユーザーが不在の場合（キープアライブが必要かどうかの決定がまだ満たされていない場合）であっても、認証が期限切れになるのを防ぐ必要があります。もちろん、これらは追加の呼び出しであり、プロトコルの追加の複雑さです。興味深いのは、サーバーが自動的にトークンを延長することです。セッションベースの環境では、タイムスタンプをリセットすることで発生しますが、ここではサーバーが新しいトークンを送信する必要があります。毎回ではなく、トークンがR（たとえば10）分で期限切れになると送信されます。ただし、応答本文に配置することは、JSON応答プロトコルを変更することを意味し（したがって、ソリューションは侵襲的で透過的ではありません）、クライアントが処理できる追加のHTTPヘッダーを配置することは、必ずしも良いパターンであるとは限りません。私' 私のオープンポイントに答える、すぐに使えるエンタープライズパターンはありますか？プロトコルドラフトは信頼できるアイデアですか？ゼロからデザインするよりも、すぐに使えるものを使いたいです。

9 rest  authentication  architectural-patterns 

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

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

パイプとフィルターのアーキテクチャパターンは、各要素の出力が次の要素の入力になるように配置された一連の処理要素として定義されます。すべての例は、ある種の共有バッファを介して実行されるプロセス間またはスレッド間接続を考慮しているようです。 私には、Haskell関数構成が同じタスクを実行しているようです。関数の順序付けだけで、明示的なバッファーがパイプとして使用されていない場合でも、それはこのパターンのインスタンスであると言えますか？はいの場合、怠惰でない言語でも同じことが言えますか？

9 design  functional-programming  haskell  architectural-patterns 

JDOMのウェブサイトを読んでいました 。 JDOM APIがインターフェイスではなく具象クラスで定義されているのはなぜですか？ Jason Hunterは、JDOMのインターフェースベースのAPIに対する引数を要約しています。 インターフェースではすべてがファクトリーになり、要素を追加するだけでなく新しいドキュメントに「インポート」する必要があり、長期的なシリアル化などの機能は保証されず、リストは続きます。 実際にインターフェースから始めました。いくつかの同僚へのリリース前のレビュー中に、具体的なクラスを試すべきフィードバックを受け取りました。私たちはそうしました、そしてデザインはそれのためにはるかに優れていました。 私は初心者デザイナーです。私が今までについて聞いたことがすべてのアドバイスをさに対して助言具象クラスを使用した設計を使用しました。 特定の場所で適切なクラスを使用している場合があります。デザインで具象クラスを使用しても問題ない、一般的なクラスの問題はありますか？

9 java  design  object-oriented  architectural-patterns 

私の理解では、進化的アーキテクチャは、アーキテクチャを簡単に変更できるようにすることです。現在、アーキテクチャーは多くの場合、後で変更するのが難しいため、早期に正しく取得する必要があるものとして定義されています。 これはどのように組み合わされますか？進化的アーキテクチャとアーキテクチャの量を最小限に抑えることの間に違いはありますか？

8 design  architecture  agile  architectural-patterns 

アプリを入手できる各ビジネス市場（国や州）ごとに要件がわずかに異なるアプリを開発しています。それは一般的な状況のようですが、このシナリオのコード/モジュールの構造化に関する良い記事を見つけることができないようです。 これはC＃アプリであり、戦略パターンとテンプレートパターンの間で議論していますが、フォルダー構造と命名規則の考慮事項もあります。各州の個別のプロジェクトはすぐに管理できなくなるようです（たとえば、5つのコアサービスX 50州のカスタムプロジェクト）= 250プロジェクト!!）おそらく、サービスごとに1つのカスタムプロジェクトが、州ごとにサブフォルダーに編成された専門化を処理していますか？

8 c#  design-patterns  architecture  architectural-patterns 

この質問は、私を混乱させる私の申請の規則を適用することについてです。 コントローラはサービスを使用しており、サービスはリポジトリを使用しています。 public class CommentController: ApiController{ [HttpPost] public bool EditComment(Comment comment){ commentService.Update(comment); } } public class CommentService{ ICommentRepository repository; .... .... public void Update(Comment comment){ repository.Update(comment); } } ユーザーが認証されると、コメントを更新できます。 ただし、ユーザーは自分のコメントを編集する必要があります。 ただし、管理者はすべてのコメントを編集できます。 ただし、指定した日付以降はコメントを編集できません。 部門で編集 そして、私はこれらのルールのようなものを持っています。 サービスレイヤーで「ユーザー編集独自のコメント」ルールを適用すると、Update methotを変更し、コントローラーのパラメーターUser.Identity.Nameを渡します。 public class CommentService{ ICommentRepository repository; .... .... public void Update(string updatedByThisUser, Comment comment){ // …

8 architecture  asp.net-mvc  architectural-patterns 

リポジトリパターンを使用するMVCサイトがあります。MVCスタイルを十分に使用しているようには思えないので、その一部を再構築する準備をしています。しかし、私もそれを実行したいので、フロントエンドが変更された場合は、交換しやすくなります。 これが私が現在持っているものです モデル-一部のモデルには、エンティティ/クラスが直接含まれています。（ログインモデルにはCustomerクラスが含まれます。これは、Customerテーブル/リポジトリクラスと直接相関しています）ビュー-ビューの一部にリポジトリクエリが含まれています-つまり _customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name); コントローラー-ここではそれほど大きな問題ではありません。コントローラーはいくつかのレポクエリを呼び出します。一部のコントローラーはいくつかのサービスを使用してレポを呼び出します-すなわち _customerService.GetAllCustomers() 呼び出す _customerRepo.Query().All(); これが私の考えです。 1）モデルには、ビューに表示する必要があるデータのみを含める必要があります。Customerテーブル/オブジェクトのすべてのプロパティがビューに表示されている場合でも、ビューがデータベースアーキテクチャまたはバックエンドオブジェクトについて何も認識しないように、それらを独自のモデル/クラスに書き直す必要があります。 2）ビューはモデルオブジェクトにのみアクセスする必要があります 3）（そして、これは私がとるべき道に苦労しているところです） a）コントローラー（またはMVC側のどこか）は、repo / servicesから返されたオブジェクトデータを変換してモデルに変換するコードである必要があります。このコードをモデルコンストラクターに配置できると想定していますが、検証エラーがある場合に備えて、DIはデフォルトの空のコンストラクターを想定していることに気付きました b）コントローラは、データを取得するための適切な名前の付いたメソッド（つまり、_customerRepo.GetAllCustomers（））でrepoインターフェースを呼び出します c）コントローラはサービス層にのみアクセスします。サービスレイヤーは、リポジトリレイヤーとやり取りする唯一のものです。 モデル、コントローラー、サービス、リポジトリのレイヤーを抽出しすぎていますか？サービスレイヤーはすべてリポジトリで実行できるため、オーバーヘッドが多すぎませんか？ オブジェクト/ビジネスエンティティをモデルに変換するための推奨アプローチは何ですか？

8 design-patterns  architecture  asp.net-mvc  architectural-patterns 

ドメインモデルファクトリを実装する方法と場所を理解しようとしています。Company集計を、それをどのように行ったかのデモとして含めました。 私は最後に私の設計決定を含めました-それらの点に関するコメント、提案、批評をいただければ幸いです。 Companyドメインモデル： public class Company : DomainEntity, IAggregateRoot { private string name; public string Name { get { return name; } private set { if (String.IsNullOrWhiteSpace(value)) { throw new ArgumentOutOfRangeException("Company name cannot be an empty value"); } name = value; } } internal Company(int id, string name) { Name …

8 design  domain-driven-design  domain-model  architectural-patterns 

Mark Seemannの 'Ploeh'ブログを含むいくつかのソースで、IoCコンテナーのコンポジションルートの適切な配置がアプリケーションのエントリポイントに可能な限り近いことについて読んだことがあります。 .NETの世界では、これらのアプリケーションは、一般的にWebプロジェクト、WPFプロジェクト、コンソールアプリケーション、一般的なUIを持つもの（読み取り：ライブラリプロジェクトではない）と考えられているようです。 構成ルートをライブラリプロジェクトのグループの論理的なエントリポイントを表し、このようなプロジェクトグループのクライアントが他の誰かの作業である場合、構成ルートをライブラリプロジェクトのエントリポイントに配置することは、この賢明なアドバイスに本当に反していますか？ 、その作者が自分のプロジェクト（UIプロジェクトまたはさらに別のライブラリプロジェクトでさえ）にコンポジションルートを追加できない、または追加しないだろう？ 私はIoCコンテナー実装としてNinjectに精通していますが、必要なすべてのバインディング構成を含むモジュールをスキャンできるという点で、他の多くも同じように機能すると思います。これは、バインディングモジュールを独自のライブラリプロジェクトに配置して、メインライブラリプロジェクトの出力でコンパイルできることを意味します。クライアントが構成を変更したい場合（私のケースではありえないシナリオ）、置換DLLをドロップして、バインディングモジュールを含むライブラリ。 これにより、最も一般的なクライアントが依存関係の注入とコンポジションのルートを処理する必要がなくなり、ライブラリプロジェクトグループのAPIが最もクリーンになります。 しかし、これはこの問題に関する従来の知恵に直面して飛んでいるようです。そこにあるほとんどのアドバイスは、開発者が自分のケースではなく、UIプロジェクトの開発にも何らかの調整を行っていることを前提としているだけですか？

8 design-patterns  .net  dependency-injection  architectural-patterns  ioc-containers 

私の会社は私を助けてもらうために求人情報を投稿しました。今日採用担当者から電話があり、彼が言い続けたのは「MVC this Entity Framework that ...」だけでした-プロジェクトがWinFormsとASP.NET WebFormsでDataSetsとLinq2Sqlを使用すると言ったとき、彼はショックを受けました。 それから私は自動化されたウェブサイトのテストのためのオプションを探していて、ここでこれに出くわしました：そして私は興奮し始めました。 「知っている」ほとんどの人は、プレゼンテーションレイヤーを使用してASP.NETを非常に薄くしているため、NUnitAspのようなツールは役に立ちません。 この人は知っている、そして彼の友人は明らかに知っている。知らないうちにいると不安になり、少し悲しくなります。 この1年で時代に対応するための取り組みの中で、Linq2SqlとUnityコンテナーの大きなメリットを実感しました。どちらも私にとっては良いものでした-何年にもわたって私には明らかだったギャップを埋めることです。 その後、WinForms GUIのModel-View-Preseneterに移動しましたが、同じ理由で再びとても満足していました-長い間、私はシッククライアントとWebを分離できるように物事を分離する方法を求めていましたクライアントは共通のコードベースで共通のロジックを共有します。 しかし、私は次のことに苦労しています。そして、私は無数の人々が間違っていることはないことを知っています、そして私は大衆より賢くありませんが、私は見るために助けが必要です： WebFormsの進化としてのMVC WinFormsの進化としてのWPF Linq2Sqlの進化としてのエンティティフレームワーク（そして、さらに言えば 、データセットの非推奨） （これはすべて、これまでのところ、テストファーヴェルニュゲンを入手できなかったことに起因していると思います） したがって、私は自分自身に尋ねてきました。 WebアプリケーションでMVCを使用すると何が得られますか？追加のソースコードアーティファクトと新しいDSLを習得することを知っています。ほかに何か？ MVVMパターンなしでWPFオブジェクトを使用するとどうなりますか？どこか他の場所に就職するチャンスを傷つけませんか？ それに関して、WinFormsは本当に壊れているのですか？それは私ですか、それとも、8ギガのRAMを搭載したデュアルコア2.8 GHZマシンでVisual Studioに顕著な視覚的遅れがありますか？私はきびきびと好きです。エンドユーザーにはいつでもスッキリと体験して欲しい。 データセットが「古い方法」である理由 それらは、私が解決しなければならない多くの中小規模の問題に対して、迅速かつ効率的で簡潔に見えます（ただし、Silverlightにさえありません）。 プレートには複雑な山がたくさんあり、それを広げても消えないように感じます。本質的な量の複雑さは正面から向き合う必要があり、おそらくソフトウェアエンジニアリングは電気工学や機械工学、または脳外科手術のようになるはずです。

8 design-patterns  mvc  mvvm  architectural-patterns