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

3層（DAL、BL、UI）でアプリの構築を開始しました[主にCRM、いくつかの販売レポート、在庫を処理します]。 同僚から、サービスレイヤーパターンに移行する必要があり、開発者が経験からサービスパターンにアクセスするようになったと言われました。彼は、将来そのようにアプリケーションを維持する方がはるかに簡単になるだろうと言いました。 個人的に、私はそれが物事をより複雑にしているだけだと感じており、それを正当化するような利益はあまり見られませんでした。 このアプリには、デスクトップアプリケーションの機能の一部（ただしごくわずか）を使用する小さな部分UIが追加されているため、コードを（あまり多くは）複製していません。いくつかのコードの重複のために、私はそれをサービス指向に変換しませんが、一般的にそれは非常に優れたアーキテクチャであるため、とにかくそれを使用するべきだと言いました。 私はそれでグーグルしようとしましたが、私はまだ混乱しており、何をすべきかを決めることができません。

68 design-patterns  architecture  web-services  services  service 

人々のGetリクエストにxml / jsonを提供するasp.net MVC Webサービスフレームワークがありますが、ユーザーを認証するための最良の方法（javascriptまたはOO言語でコーディングするユーザーにとって高速、簡単、簡単）を見つけるのに苦労しています。データが機密であるなどということではなく、ユーザーに登録してもらい、変更を通知して使用状況を追跡するための電子メールアドレスを用意するだけです。 以前の試みでは、URIにユーザー名があり、ユーザー名が存在することを確認し、使用に応じてdbテーブルをインクリメントするだけでした。これは非常に基本的なことでしたが、ユーザー名などとしてデモを使用している人がいることに気付くので、もう少し洗練させる必要があります。 利用可能な認証技術は何ですか？主要なプレーヤーは何を使用/しますか。

26 security  api  web  services  rest 

変更のための先見の明を持つ外部アプリケーション用のAPIを設計しようとすることは簡単ではありませんが、少し前もって考えておくことで、後で生活が楽になります。私は、以前のバージョンのハンドラーをそのままにしておくことで、後方互換性を維持しながら将来の変更をサポートするスキームを確立しようとしています。 この記事の主な関心事は、特定の製品/会社に対して定義されたすべてのエンドポイントでどのパターンに従う必要があるかです。 基本スキーム のベースURLテンプレートを考えると、https://rest.product.com/すべてのサービスが/api、/authおよびなどの他の非レストベースのエンドポイントと共に存在することを考案しました/doc。したがって、次のようにベースエンドポイントを確立できます。 https://rest.product.com/api/... https://rest.product.com/auth/login https://rest.product.com/auth/logout https://rest.product.com/doc/... サービスエンドポイント 次に、エンドポイント自体について説明します。懸念はPOST、GET、DELETEこの記事の主な目的ではなく、それらのアクション自体に懸念されます。 エンドポイントは、名前空間とアクションに分類できます。また、各アクションは、戻り値の型または必須パラメーターの基本的な変更をサポートする方法で表示される必要があります。 登録されたユーザーがメッセージを送信できる架空のチャットサービスを利用すると、次のエンドポイントがある場合があります。 https://rest.product.com/api/messages/list/{user} https://rest.product.com/api/messages/send 今度は、壊れる可能性のある将来のAPI変更に対するバージョンサポートを追加します。私たちは、どちらかの後にバージョンの署名を追加することができ/api/たりした後/messages/。与えられたsendエンドポイント我々は、v1の以下のものを持つことができます。 https://rest.product.com/api/v1/messages/send https://rest.product.com/api/messages/v1/send だから私の最初の質問は、バージョン識別子の推奨場所は何ですか？ コントローラーコードの管理 そのため、以前のバージョンをサポートする必要があることを確立しました。そのため、時間の経過とともに廃止される可能性のある新しいバージョンのそれぞれのコードを何らかの方法で処理する必要があります。Javaでエンドポイントを記述していると仮定すると、これをパッケージで管理できます。 package com.product.messages.v1; public interface MessageController { void send(); Message[] list(); } これには、すべてのコードがネームスペースを介して分離されているという利点があります。この場合、重大な変更はサービスエンドポイントの新しいコピーを意味します。これの不利な点は、すべてのコードをコピーする必要があり、新しいバージョンと以前のバージョンに適用するバグ修正を各コピーに適用/テストする必要があることです。 別のアプローチは、エンドポイントごとにハンドラーを作成することです。 package com.product.messages; public class MessageServiceImpl { public void send(String version) { getMessageSender(version).send(); } // Assume we have …

25 design  design-patterns  web-services  rest  services 

アプリケーションをサービスに分割しようとしているとしましょう。SOAアプローチを採用する理由と、それを必要とするアプリケーションがロードできるライブラリAPIを作成する理由はありますか。

22 api  soa  services 

貧血のドメインモデルは、 Martin Fowler氏によってドメイン駆動設計におけるアンチパターンとして記載されています。ドメインモデルでビジネスロジックを使用するには、多くの場合、ドメインサービスが使用されます。ただし、ドメインモデルへのドメインサービスの注入は、Vaughn Vernonにとって有害で​​あると考えられています（「ドメイン駆動設計の実装」を参照）。 私の意見では、これらの意見は矛盾している、これは本当ですか？両方のポイントをどのように考慮することができますか？ それは実際にされたドメインサービスと豊富なドメインモデルは、注入された対貧血のドメインモデルと通常のドメインサービス？

19 domain-driven-design  dependency-injection  services 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 4年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 Windowsサービスを使用するのは初めてです。VS2010でWindowsサービスを作成することを学びましたが、Windowsサービスを使用できる実用的な方法を知りたいですか？ 現在のコンテキストを念頭に置いてグーグルを試し、Windowsサービスの作成方法に関するチュートリアルをさらに見つけました。 バウンティオファーの編集： すべての答えは素晴らしいですが、私はWindowsサービスとその意味に関するより実用的な例を探していましたか？これは、開発者がケーススタディでそれらを使用するのが適切である時期を知るのに役立ちます。

18 c#  .net  windows  visual-studio-2010  services 

私は新しいアプリケーションを構築しており、マイクロサービスアーキテクチャについて読んでいました。アーキテクチャ自体は、開発、展開、ライフサイクル管理の観点から非常に理にかなっています。しかし、出てきた問題の1つは、マスターデータの処理方法に関するものでした。 たとえば、2つのアプリがあります。たとえば、SalesアプリとTicketingアプリです。これらのアプリは両方とも独自のマイクロサービスとして構築されていると仮定します。ただし、これらのアプリの両方をデプロイする場合（セールスがMongoDBを使用し、チケットがMariaDBを使用すると言う場合）、別々にデプロイすると、アカウント、製品などの同じマスターデータインスタンスにアクセスする必要があります。これは、特定のマスターデータエンティティの所有者アプリ（例：アカウントの場合は販売アプリ）と関係者（例：発券アプリにはアカウントに関する情報が必要）があることを意味します。 これを実現する方法は複数あります。-マスターから関係者へのデータ複製-関係者からマスターへの同期読み取り（同期依存関係はマイクロサービスアーキテクチャパラダイムでは推奨されません）-独自の中央リポジトリ また、アカウント内でも、販売と発券の両方に共通のコア部分（アカウント名、住所など）が存在する場合があります。ただし、アカウントの一部の側面は販売にのみ関連し、他の側面はチケットにのみ関連する場合があります。 上記のオプションのいずれかに関する考え/ベストプラクティス/意見はありますか？

14 soa  services 

私が取り組んでいる場所は、いくつかの基本的なルールを確立しようとしています。そして、私たちが現在持っている議論は、コードを再利用するためのローカルライブラリとWebサービスです。Webサービスは、ほとんどの企業で人気のある選択肢のようです。そして、それは、ここの開発者のほとんどが傾いていることです。 深刻な仕事にWebサービスを効果的に使用する方法がわかりません。トランザクションを使用できない場合、どうすれば複数のサービスコールを安全に実行できますか？ 通知が必要な特定の条件を満たす顧客をデータベースから取得するcronジョブがあるとします。ファックス、電子メールが送信され、チケットを作成して問題を内部的に追跡します。これは、forループの各顧客に対して発生する3つの異なるサービスコールです。 そこのどこかでエラーが発生した場合、たとえば、ファックスとメールが顧客に送信されても​​、チケットは作成されない可能性があります。さらに悪いことに、このcronジョブにはバグが含まれていて、毎回同じポイントで失敗し、同じ顧客に繰り返しメールを送信する可能性があります。ライブラリがすべてローカルである場合、すべてをトランザクションにラップすることができますが、それはまったく起こりません。ただし、この例ではWebサービスを使用しています。 電子メールとFAXのメソッドは、実際にはデータベースにバックアップされたキューテーブルにデータを挿入します。これは、別のcronジョブプロセスによって処理されます。したがって、「電子メールの送信」および「ファックスの送信」サービスメソッドの呼び出しは、必要に応じて副作用なしで中止できます。 オプションは、このコード全体をWebサービス自体に配置することです。そのため、Webサービス自体は、トランザクションで電子メール、ファックス、およびチケット作成メソッドを呼び出します。ただし、トランザクションを使用するためだけにWebサービスメソッドを作成しています。この1つのcronスクリプト以外のどこからでも実際にこのメソッドを呼び出す必要がある正当な理由はありません。 このメソッドを一般的にどのように処理しますか？

14 web-services  soa  services 

コントローラーが太りすぎて、モデルのインスタンス化が増え始めると、サービスレイヤーを使用できます。 サービスクラス内にロジックをラップするだけの場合、1つまたは2つのメソッドで多数のサービスを取得します。これはコード臭のように感じます。これに関するベストプラクティスはありますか？ サービスはモデルをインスタンス化できますか？ サービスがモデルをインスタンス化する場合、サービスを単体テストすることはできません。それらは統合テストでのみカバーできますか？

12 mvc  services 

私はマイクロサービスについて読みましたが、分離を実現するためだけにサービスごとに個別のDBを作成するのは私には非論理的です。Webサービスと単一のデータベースのみを使用して同じことを実現できます。なぜそれが必要なのですか？データベースを分離することは議論の余地があります。または私は明らかに間違っていますか？これについて教えてくれませんか？

10 architecture  database  web-services  microservices  services 

私はアーキテクチャで作業しています。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 

ですから、これまで取り組んできたアプリをリリースするのに非常に近づいており、統合するサーバーでユーザーを登録できます。そのため、ユーザーがアプリを使用する前にアプリに登録する必要があるかどうか疑問に思いました。アプリは機能の登録を「必要とする」ことはありません（ただし、ユーザーのデータをクラウド内のアカウントに保存できる将来の更新についてはいくつかのアイデアがあります）が、それでもリストを用意しておくと便利です登録ユーザー。 ユーザーに登録を要求する必要があると思う理由の1つは、アプリが初めて起動したときに、ユーザーが私のプライバシーポリシーと利用規約に同意する必要があるためです。したがって、登録画面を作成した場合は、ユーザーを法的な言葉で攻撃するよりも、簡単でわかりやすいかもしれません。 しかし、ユーザーに登録を要求すると、一部のユーザーに費用がかかると思います。一度アプリをダウンロードしたところ、登録を求められましたが、怠惰でした。それは登録を要求することに対する正当な恐れですか？ ありがとう！ 編集： 明確にするために、登録が必要だった場合、どの情報を収集する必要がありますか：名前、電子メール、パスワード？その他？そして、私たちはそれらを電子メールでまったくスパムしないでしょう。また、非常に強力なプライバシーポリシーがあり、すべてのデータを安全に保存します。

9 ios  app  services  terms-of-service