2

EF なしで、おそらく LINQ なしで ASP.NET MVC を使用しようとしています。まず、VS2010 の基本的な ASP.net mvc テンプレートにテーブル/モデル/コントローラー/ビューを 1 つだけ作成しました (インデックス ページと Index メソッドのみが実装されています)。Web 上のすべてのチュートリアルは EF に基づいており、c のバックグラウンドが埋め込まれているため、現在試行錯誤を行っています。

私の質問は次のとおりです。

  • アーキテクチャは正しいですか?

  • リポジトリ パターンが、nearforum などのオープン ソース プロジェクトで使用されているのを見ました。その利点は何ですか?また、これにどのように適合しますか?DAL に取って代わるものですか?

  • データテーブルを表すビューまたはオブジェクトにデータテーブルを渡す必要がありますか?

  • 複数のモデルを剃刀ページに渡すことはできますか? たとえば、2 つの異なるテーブルを一覧表示するにはどうすればよいですか?

  • すべての DAL コードを 1 つのファイルに入れる方がよいでしょうか?

ダル:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data;
using System.Configuration;
using MySql.Data.MySqlClient;

namespace MvcApplication1.Models
{
  public class DAL
  {
    public DAL()
    { }
    public DataTable getDataTable(string tableName)
    {
      using (MySqlConnection conn = new MySqlConnection(ConfigurationManager.ConnectionStrings["MySQLConn"].ConnectionString))
      {
        using (MySqlCommand command = conn.CreateCommand())
        {
          command.CommandText = "select * from " + tableName;
          command.CommandType = CommandType.Text;

          conn.Open();

          var table = new DataTable();
          table.Load(command.ExecuteReader());

          return table;
        }
      }
    }
  }
}

コード内の Product テーブルを表す Product.cs クラス:

namespace MvcApplication1.Models
{
  public class Product
  {
      public int ProductId { get; set; }
      public string Name { get; set; }
      public string Producer { get; set; }
      public int UnitPrice { get; set; }
  }
}

ProductController.cs

namespace MvcApplication1.Controllers
{
    public class ProductController : Controller
    {
        //
        // GET: /Product/
      DAL dal = new DAL();
        public ActionResult Index()
        {
          DataTable dt = dal.getDataTable("Product");
          Product[] products = new Product[dt.Rows.Count];
          for (int i = 0; i < dt.Rows.Count; i++)
          {
            products[i] = new Product();
            products[i].ProductId = (int)dt.Rows[i]["ProductId"];
            products[i].Name = (string)dt.Rows[i]["Name"];
            products[i].Producer = (string)dt.Rows[i]["Producer"];
            products[i].UnitPrice = Decimal.ToInt32((decimal)dt.Rows[i]["UnitPrice"]);
          }

          return View(products);
        }
........
........
}

インデックス.cshtml:

@model IEnumerable<MvcApplication1.Models.Product>
@{
    ViewBag.Title = "Index";
}

<h2>Index</h2>
@foreach (var item in Model)
{
    <tr>
        <td>
            @Html.DisplayFor(modelItem => item.ProductId)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.Name)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.Producer)
        </td>
        <td>
            @Html.DisplayFor(modelItem => item.UnitPrice)
        </td>
        <td>
            @Html.ActionLink("Edit", "Edit", new { id=item.ProductId }) |
            @Html.ActionLink("Details", "Details", new { id=item.ProductId }) |
            @Html.ActionLink("Delete", "Delete", new { id=item.ProductId })
        </td>
        <br>
    </tr>
}
4

1 に答える 1

3

リポジトリ パターンは、nearforum などのオープン ソース プロジェクトで使用されているのを見ました。その利点は何ですか?また、これにどのように適合しますか?DAL に取って代わるものですか?

リポジトリ パターンの利点は、データ アクセス ロジック/ORM を切り替えることができることです。たとえば、Entity Framework から NHibernate に切り替えたい場合は、IoC コンテナー内の登録を更新するだけで、コードは魔法のように切り替えを行ったことをまったく知らずに NHibernate を使用します。これにより、コードが基礎となる永続化フレームワークにとらわれないようにすることができます。結果コードは、ファイル、Web サービス呼び出し、またはメモリ内リストから取得されます。別のコンポーネントから同じクエリを作成する必要があった場合にも、再利用できます。もう 1 つの利点は、単体テストです。現在の実装では、コントローラーは毎回データベースに直接接続するため、コントローラーを単体テストすることはできません。したがって、定義上、統合テストになります。ORM を活用したいと思うことは間違いありません。さもなければ、泣くまで同じコードを何度も書くことになるでしょう。接続のセットアップ/破棄、すべてのプリミティブのネイティブ .NET 型への型キャストなど。ネイティブ ADO.NET を扱うことは、今日では過去のものです。あなたの人生を楽にし、ORM を使用してください。同時に、大きな力には大きな責任が伴います。データベースに対して生成および実行されるクエリを検証しない場合、ORM は悪夢になる可能性があります。適切に使用しないと、パフォーマンスの問題が発生します。ほとんどのクエリで LINQ を活用できますが、場合によっては、ダーティーでファンキーなネイティブを取得して、生の SQL を使用する必要があります。ORM は引き続き両方のシナリオを処理できます。接続のセットアップ/破棄、すべてのプリミティブのネイティブ .NET 型への型キャストなど。ネイティブ ADO.NET を扱うことは、今日では過去のものです。あなたの人生を楽にし、ORM を使用してください。同時に、大きな力には大きな責任が伴います。データベースに対して生成および実行されるクエリを検証しない場合、ORM は悪夢になる可能性があります。適切に使用しないと、パフォーマンスの問題が発生します。ほとんどのクエリで LINQ を活用できますが、場合によっては、ダーティーでファンキーなネイティブを取得して、生の SQL を使用する必要があります。ORM は引き続き両方のシナリオを処理できます。接続のセットアップ/破棄、すべてのプリミティブのネイティブ .NET 型への型キャストなど。ネイティブ ADO.NET を扱うことは、今日では過去のものです。あなたの人生を楽にし、ORM を使用してください。同時に、大きな力には大きな責任が伴います。データベースに対して生成および実行されるクエリを検証しない場合、ORM は悪夢になる可能性があります。適切に使用しないと、パフォーマンスの問題が発生します。ほとんどのクエリで LINQ を活用できますが、場合によっては、ダーティーでファンキーなネイティブを取得して、生の SQL を使用する必要があります。ORM は引き続き両方のシナリオを処理できます。大きな力には大きな責任が伴います。データベースに対して生成および実行されるクエリを検証しない場合、ORM は悪夢になる可能性があります。適切に使用しないと、パフォーマンスの問題が発生します。ほとんどのクエリで LINQ を活用できますが、場合によっては、ダーティーでファンキーなネイティブを取得して、生の SQL を使用する必要があります。ORM は引き続き両方のシナリオを処理できます。大きな力には大きな責任が伴います。データベースに対して生成および実行されるクエリを検証しない場合、ORM は悪夢になる可能性があります。適切に使用しないと、パフォーマンスの問題が発生します。ほとんどのクエリで LINQ を活用できますが、場合によっては、ダーティーでファンキーなネイティブを取得して、生の SQL を使用する必要があります。ORM は引き続き両方のシナリオを処理できます。

データテーブルを表すビューまたはオブジェクトにデータテーブルを渡す必要がありますか?

確かにデータテーブルを渡したくありません。ビュー モデルまたはエンティティをビューに渡したい。ビューはデータベースについて何も知らないはずです。データを与えるだけで、そのデータのソースを知らずに画面に表示されます。遅延読み込みや N + 1 クエリに関連する問題が発生するため、NHibernate などを使用している場合は、エンティティをビューに直接渡すことに注意する必要があります。ビュー モデルは通常、エンティティのスリム化されたバージョンです。たとえば、4 つのプロパティを持つエンティティがあり、ビューがそれらのプロパティの 2/4 のみを消費する必要がある場合、2 つのプロパティを持つ別のビュー モデルを作成し、Automapper などのマッピング ライブラリを使用してエンティティからビューにマッピングします。モデル。

複数のモデルを剃刀ページに渡すことはできますか? たとえば、2 つの異なるテーブルを一覧表示するにはどうすればよいですか?

これは非常に簡単です。トップレベルのオブジェクトを作成し、アクセスしたいエンティティを表す 2 つのプロパティを与えます。

public class MyViewModel
{
  public Entity1 FirstObject { get; set; }

  public Entity2 SecondObject { get; set; }
}

次に、強く型付けされたビューを作成し、質問に投稿されたカミソリ ビューで使用した強く型付けされたビュー ヘルパーを使用して、FirstObject と SecondObject をレンダリングします。@Html.TextBoxFor() など

最後に、コントローラーは MyViewModel を引数として受け取り、ビューにレンダリングされたフォーム入力に基づいて FirstObject と SecondObject を設定します。

すべての DAL コードを 1 つのファイルに入れる方がよいでしょうか?

関連する DAL コードを同じファイルに入れたい。通常、物事はテーブルごとにマップされますが、それはすべてオブジェクト間の関係に依存します (たとえば、集計ルートは何か)。やりたくないことは、テーブルごとに 1 つのリポジトリをやみくもに実装することです。データベースへの複数の呼び出しを介してオブジェクト グラフとリレーションシップをつなぎ合わせる、本当に手続き的で貧弱なデータ モデルになってしまうだけです。この問題に取り組む方法について良いアイデアを得るために、ドメイン駆動設計を調べることをお勧めします。

ここでは表面をなぞっただけです。これを適切に行うには、基本的に最新のパターンとプラクティスを習得する必要があります。全部違う動きです。ファイル、ビュー ステート、および DataGrid コントロールの背後にあるモノリシック コードの古き良き時代とは異なります。次のような本当に良い本があります。

ブラウンフィールド アプリケーション開発 ドメイン駆動設計 (Eric Evans) クリーン コーダー (Robert C Martin) リファクタリング: 既存コードの設計の改善 (Martin Fowler) エンタープライズ アプリケーション アーキテクチャのパターン (Martin Fowler)

これらすべての本を逐語的に読むように言っているわけではありませんが、最初の 2 つを強くお勧めします。コミュニティはこれらの開発プラクティスについてさらに多くのことを言うと確信していますが、これはすべてに対する私の見解です。ありがとう、そして幸運を祈ります。

于 2013-01-18T21:14:07.880 に答える