3

私は現在、2つの異なるシステムを接続するための統合プロジェクトに取り組んでいます。
私の計画は、システムAがHTTP-POSTを介してシステムBにコマンドを発行できるようにHTTP-APIを設定することです。
コマンドは、SQLサーバーデータベースにCRUD命令を発行して、メンバーシップカードデータを取得および更新するために使用されます（例：'メンバーシップの作成'、'メンバーシップの更新'など）、データをXMLとしてシステムAに返します。n層の設計では、いくつかのプロパティを持つMembershipCardクラスが必要であることがわかっています。 

public class MembershipCard
{
    private string number;
    private decimal points;

    public string Number
    {
        get { return number; }
        set { number = value; }
    }

    public decimal Points
    {
        get { return points; }
        set { points = value; }
    }

DALを呼び出すいくつかのメソッドとともに： 

    public string GetPoints(string cardnumber) 
    {
        return MembershipCardDB.BalanceRequest(cardnumber);
    }

ただし、静的DALクラスとしてこのアプローチを正当化するのは難しいです。MembershipCardDBは必要なすべての作業を実行しているようです（以下を参照）。

    public static string BalanceRequest(string cardNumber)
    {
        string response = string.Empty;
        string sqlselect = 
            "SELECT Balance                         " +
            "FROM tbl_MemberShipCard                " +
            "WHERE Card_No = @cardNumber                 " +
            "FOR XML PATH ('Card'), ROOT('CardBalance')";

        using (SqlConnection connect = new SqlConnection("Data Source=TEST\\TEST;Initial Catalog=TEST;User Id=sa;Password=TEST"))
        {
            connect.Open();
            using (SqlCommand command = new SqlCommand(sqlselect))
            {
                command.Parameters.AddWithValue("@cardNumber", cardNumber);
                response = (string)command.ExecuteScalar();
            }
        }
        return response;
    }

MembershipCardクラスを削除し、データベースからデータをプルしてXMLとしてフォーマットするだけで、見落としているものはありますか？

4

4 に答える 4

2

重要なのは、データベースインターフェイスやxml形式から独立してプログラムロジックを記述できる必要があるということです。すべてのデータベースのものを、オブジェクトをロードして作成する別のクラスに配置します。オブジェクトでやりたいことは何でもします。最後に、オブジェクトをデータベースまたはxmlに保存します。ただし、コードがデータのインポートとエクスポートのみを対象としている場合は、余分なクラスを削除できます。

ちなみに、MembershipCard自動実装されたプロパティを使用すると、クラスを簡略化できます。

public class MembershipCard
{
    public string Number { get; set; }
    public decimal Points { get; set; }
}

私はしばしば静的DBクラスを持っています

public static class DB
{
    public static string GetBalanceRequest(string cardNumber)
    {
        ...
    }

    public static MembershipCard LoadMembershipCard(string cardNumber)
    {
        ...
    }

    public static List<MembershipCard> LoadMembershipCards()
    {
        ...
    }

    public static void SaveMembershipCard(MembershipCard membershipCard)
    {
        ...
    }
}

あなたのMembershipCardクラスはメソッドを持つことができます

    public string BalanceRequest()
    {
        return DB.GetBalanceRequest(this.Number);
    }

このように、データベース操作と他のアプリケーションロジックを分離できます。

于 2012-10-02T20:40:24.143 に答える
1

建築は面白いものです。パラダイムを選択する前に、それが何を達成しようとしているのかを正確に評価することが常に最善です。

n層設計によって後で時間を節約できる場合もありますが、今日作成しなければならない余分なコードの量がそれだけの価値がない場合もあります。あなたが言っていることから、あなたはすでに後者の陣営に入っているように聞こえます。

それで、私の最初のステートメントに戻って、あなたは自分自身に尋ねるべきです：あなたはデータフォーマット（XML）を検索（SQLクエリ）から分離する必要性を予見しますか？

確かにそうなる場合があります。たとえば、XMLは非常に冗長であり、後で必要にならない可能性のある多くの非情報データが含まれています。SQL ServerがXMLを出力する方法に自分自身を結び付けることで、JSONを使用することにした場合の書き直しを検討することになります。

さらに言えば、XMLやJSONでさえ、一度に数レコードなどの限られた量のデータには問題ありませんが、一度に数百または数千のデータを転送し始めると、データの量は簡単に必要なポイントに達する可能性があります有線でCSVファイルに似たものを送信します。繰り返しますが、あなたは書き直しに直面するでしょう。

ただし、さまざまなフォーマット要件を処理するために新しいプロバイダーをプラグインするだけでビルドできる場合は、古いコードの潜在的に大きなパッチを置き換えるのではなく、新しいコードを作成します...また、複数のフォーマットを同時にサポートするのはかなり簡単です（XML、Json、CSV、Excelなど）フォーマットが検索と緊密に結合されていない場合。

小さなシステムについて話している場合、フォーマットの変更によるコードの書き換えに費やす時間は取るに足らないものである可能性があるため、悪魔の主張を演じることは重要ではありません。その時点では、n層モデルの構築に時間を費やすことはありません。 。

それがお役に立てば幸いですが、最終的にはどちらに進むべきかを教えてくれるとは思いません。

于 2012-10-02T21:23:49.707 に答える
1

特にCRUD操作を公開している場合は、RESTインターフェースが最適な方法かもしれません（Web APIを参照）。このルートを使用すると、データベースクラスを直接使用することが正当化されると思います。これは実際にはN層アプローチの違反ではありません。Webサービスは実際にはデータ層へのインターフェイスとして機能します。

これをさらに一歩進めて、現在のビルドのODataサポートを使用して、サービスに対する実行遅延クエリを公開することもできます。

主な問題は、Web APIがまだベータ版であり、定期的に変更されていることです。たとえば、ODataのサポートは、リリースプレビューにはほとんどありません。ナイトリービルドでははるかに高度です。

于 2012-10-02T21:01:34.653 に答える
0

n-tier design dictates that I should have a MembershipCard class with several properties

I'm not sure this is accurate. I think n-tier design dictates that each layer depends only on the layers below it. And each layer doesn't need to only depend on the layer directly below it - you can skip levels. So your web service interface can skip the domain layer and go directly to a repository. Although even then its best to add another layer in-between called, say, 'Application' which gives you space to add in extra non-data-access logic rather than have it leak into your UI/Web Service.

'Console.ReadLine' in your DB access class is mixing the UI in with a repository so that's obviously not good. Plus, using static methods makes it difficult to write unit tests so that's also not good.

Check out... Domain Driven Design by Eric Evans.

于 2012-10-02T21:23:23.517 に答える