1

私は彼のWCFサービスにある男のいくつかのコードを見直しています:

[ServiceContract]
public interface IDBService
{
    [OperationContract]
    void DBUpdateInsert(string sql, params string[] parameters);

    [OperationContract]
    object DBSelect(string sql, params string[] parameters);
}

また、SQL コードの呼び出しを必要とするすべての関数は、このサービスを使用します。

そのような方法の長所と短所は何ですか？私にはとても不確かなようです。

4

1 に答える 1

8

身震い。これは API ではなく、穴です。SOA の要点の 1 つは、さまざまな部分を分離することです。これにより、DB への小さな変更がサービス呼び出し元に影響を与えないようにすることができます。ここで、呼び出し元は生の SQL を提供します。つまり、DB の近親相姦の知識が必要です。したがって、カプセル化に違反します。ただし、他にも重大な問題があります。

最も重要な：

  • サービスを利用すると、発信者を信頼できなくなります。それはあなたのアプリケーションかもしれませんが、誰かがアプリを見て、接続先を見て、自分のコードからあなたのサービスを使用している可能性があります。サービス アプリケーションに入るものは何も信用できません。確かにSQLではありません。Web アプリケーションで実行する HTML ページに生の SQL を非表示の入力として (おそらく) 置かないのと同じです。

また：

  • セキュリティ: 発信者がアクセスできる/できないものは? 彼らは発行でき"delete from Orders"ますか？発信者ができる/できないことをサニタイズする能力がありません
  • string[]パラメータ - すべての値が文字列として明確であるとは限りません。これは、データモデルを理解していないことを示しています-単なる「もの」
  • 戻ります-とにかくobject、それはデータ契約ではないため、ほとんどのWCFバインディングでは機能しません-ただし、寛大に感じている場合は許してくださいNetDataContractSerializer

繰り返しますが、これはAPIではありません。API は、型指定されたパラメーターを使用して、よく知られた制御されたサービスの下で秘密のデータを公開します。適切な API を設定するには、個々のメソッド (「制御」側) から OData など (「オープン」側) まで、12 通りの方法がありますが、SQL を渡す方法はありません。

推測してみると、この開発者は SQL に直接アクセスできるリッチ クライアント アプリケーションを作成しており、サービスを介してデータを公開するように指示されていました。実際にサービスを作成するのではなく、WCF レイヤーで既存の SQL コードを公開しただけです。それは後ろ向きです。彼らの既存の SQL コード (目立たない SQL 操作など) は、WCF レイヤーになっGetCustomerているはずです。呼び出し元のクライアントは、既知の SQL をすべて忘れて、代わりに WCF サービスにバインドする必要があります。

于 2013-05-29T11:34:49.503 に答える