問題タブ [api-design]

あるプロジェクトのために書いている DAO ライブラリの返品の正しい処理に関連する質問があります。このライブラリはおそらく別の人が使用する予定であり、私はそれを正しく行いたいと考えています。DAO の関数の return ステートメントをどのように処理すればよいですか?

例 1 String を返す関数 getCustomer があります。クエリが結果を返さない場合、null、空の文字列を返すか、何らかの例外をスローする必要がありますか?

例 2getCutomerList ArrayList<String> 型の値を返す 関数 があります。クエリが結果を返さない場合、null を返すか、空の ArrayList を返すか、例外をスローする必要がありますか?

例 3 いくつかの SQL 例外が検出されました。どうすればよいですか、例外をスローtryするcatchか、それが発生する可能性のあるブロックを実行しますか?

私の場合に適用する「良い」プラクティスまたは「ベスト」プラクティスは何ですか?

ユニバーサル EPG / XMLTV サービス用の (オープンソース、別名「無料」) データソースを探していますか?

このプロジェクトには、簡単に解析できる形式で、更新された/更新可能なリアルタイム TV スケジュール情報が必要です。また、無料または非常にリベラルなライセンスで利用できる必要があります。アドバイスや代替案をありがとう。

誰かがどこから始めるべきかについて提案があれば、私は自分のソリューションをコーディングすることにオープンです。

https://api.foursquare.com/v2/venues/のような「メソッド」の API エンドポイントか、またはhttps://api.foursquare.com/v2/venues/のような非クエリ文字列パラメータを含む完全な URL です 。 5104

つまり、これら 2 つのエンドポイントは別個のものですか、それとも同じエンドポイントと見なされますか? http://myapi.com/somemodel/1
http://myapi.com/somemodel/2

Windows をターゲットにしていますが、作成している一部の API コードで基本的な C++ 型を使用できない理由がわかりません。私がやりたいことは、文字列と整数を返すメソッドを公開することです。C# の世界では文字列を使用し、Unicode 文字列を使用しますが、VC++ では、std::string、std::wstring、または MFC/ATL CString を使用するオプションがあります。

ユニコードをサポートするために std::wstring のみを使用する必要がありますか、またはビルド設定に基づいてユニコードにコンパイルされる std::string を使用できますか? 私は後者に傾いています。他の文字列型のオブジェクトに Get[Item]AsCString() メソッドを提供したいと思います。

また、整数の代わりに size_t を使用する必要がありますか?

この API は私が使用する予定であり、おそらく C++ GUI に取り組む将来の開発者も使用する予定です。懸念事項を分離する方法です。私の好み：

• 他の開発者にとっての直感性。
• VC++ との上位互換性
• 他の C++ コンパイラとの互換性
• パフォーマンス (これは私にとってはあまり問題ではありませんが、アプリの残りの部分の起動時間が必要です)

ガイドをいただければ幸いです。

私はいくつかの「パッケージ」で構成されているユーティリティライブラリを書いています。各パッケージのクラスは、さまざまな名前空間に含まれています。クラス宣言の最後にステートメントを使用して自動的に宣言することで状況を単純化する方法についての考えがあります（以下を参照）。これにより、プログラマーがcppファイルでそれを行う必要がなくなります。

私の理解では、ユーザーがヘッダーString.hを含み、StringがUtilityにある場合、プログラマーはStringを使用したいと思うでしょう。明らかに、名前空間を汚すファイルの束を含む外部のクラスチェーンがある場合、これは悪い可能性があるので、代わりに#defineにするのはどうでしょうか。

そうすれば、この拡張機能が必要なプログラマーはそれを手に入れることができます。

これは良い考えですか、それとも私が見落としているものがありますか？

C++ ライブラリを開発しています。ライブラリのさまざまなコンポーネントを含めて、Java と C# が処理する方法について考えさせられました。たとえば、Java は「インポート」を使用して他のパッケージのクラスを使用できるようにしますが、C# は単純に「使用」を使用してモジュール全体をインポートします。

私の質問は、ライブラリ内のすべてを 1 つの大規模なインクルードに #include し、using ディレクティブを使用して特定のクラスとモジュールをインポートするのは良い考えでしょうか? それとも、これはただクレイジーになるのでしょうか？

編集： これまでのところ良い反応です。ここに、この考えに追加されると私が感じるいくつかの緩和要因があります：

1)内部の #includes は通常どおりに保持されます (短く要点を示します)
2)すべてを含むファイルは、必要に応じてライブラリと共に提供され、使用したい人に提供されます
3)オプションで、大きなインクルード ファイルを pre -コンパイル済みヘッダー

この質問で十分にカバーされているSystem.Uriように、URIに対する私の意図を反映するための良い選択です。しかし、電子メールアドレスはどうですか？

プロパティMailAddressに追加の情報が含まれているため、あまり明確ではないようです。DisplayName

常に HTTPS 経由で通信する RESTful API を設計しています。HTTPS で実行するときに OAuth のようなスキームを使用する理由はありますか? 通信全体が暗号化されている場合に、HMAC 署名付きリクエスト、ナンス、タイムスタンプなどの側面が役立つかどうかに特に関心があります。

HTTPS を介した任意の認証スキームで十分なようですが、セカンドオピニオンを得たかっただけです。

perl と TAP を使用して、多くの Selenium テストを作成し、それらを *.t ファイルに保存しました。

いくつかのヘルパー関数を作成し、My::Util::SeleniumHelper などの非オブジェクト指向パッケージに入れました。

すべての関数は、このモジュールからエクスポートされます。最初は 1 つのパッケージで十分でしたが、現在では単一モジュール API に関連のない関数が多数含まれています。これらの関数は、make_sel()、head_ok()、cms_logout()、cms_login()、cms_clickthru_simple()、selenium_rc_running()、treecontrol_toggles() などで呼び出されます。

さらに、t ファイル内の多くのコード ブロックは依然として冗長であるため、.t ファイルはテンプレートのように見えます。

したがって、*.t コードをよりオブジェクト指向のデザインにしたいと考えています。

新しい API の設計方法に関するアイデアはありますか?

基本的に、誰かが巧妙な方法でセレン オブジェクトを拡張したコード例 (ここまたはインターネット上) も探しています。perl である必要はありません。

Test::WWW::Selenium オブジェクト $sel にメソッドを追加すると便利でしょうか?

$sel オブジェクトをオーバーライドする必要がありますか?, Test::WWW::Selenium::Customized クラスを Test::WWW::Selenium から派生させる

これは、 「継承よりも構成を優先する」というイディオムに違反します。

コンポジションを使用してセレンオブジェクトを別のオブジェクトにラップする必要がありますか?

以下に、さらにいくつかの要件または考えを示します。

pageObjects Pattern/Idiomも使用したいと思います。まだそうしていません。たぶんそう

また

ほとんどの場合、基本的には、ムースの around() 修飾子のようなものをセレン メソッドに与えたいと思います。標準的なことを行いますが、前後にいくつかのことを行います。

ただし、テストはいくつかの異なるマシンで実行する必要があり、これらすべての PC に Moose とそのすべての依存関係をインストールしたくないため、ここでは Moose を使用しないことを好みます。ムースを使用することが不可能だと言っているわけではありませんが、ムース以外のオブジェクト (Test::WWW::Selenium) とムース オブジェクトを一緒に使用したことはありません。

最近、既存の Web ポータル用の API を作成する際の要件に出会いました。現在の Web UI はそのまま残り、API は、コア アプリの上にアプリを構築したいすべてのクライアントに追加機能を提供します。

Web UI は非常に複雑で、必要な機能を実現するためのいくつかの段階的なフォームで構成されています。たとえば、一部のドメイン オブジェクトはウィザードのような方法で一連のフォーム ビュー (私のビューモデル) に分割されます。入力された値が int かどうか、指定された電子メールが有効かどうかなどに関する検証は、viewmodel で行われます。

ビューモデル クラスを再利用して、API でのユーザー入力を表すことを計画していました。

例 WebUI: public ActionResult Save(FormOne form){...} API: public ActionResult Save(String apiKey, FormOne form){...}

しかし、これは非常に困難です。つまり、WebUI ビューモデルと API ビューモデルを完全にマッピングする必要があります。

この場合、優れた設計とはどのようなものでしょうか?

a) API の新しいビューモデルを作成しますか? b) 可能な場合は既存のビューモデルを使用する - 適切な場所に新しいクラスを作成する c) 他に何か?

ありがとう、Y