ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

.NET Frameworkコミュの型付DataSet VS カスタムクラス

  • mixiチェック
  • このエントリーをはてなブックマークに追加
はじめまして。今日このコミュニティに登録しました。
みなさんも開発中「これでいいのかな?でも動くし・・・」って場面がよくあると思います。
巷では[patterns&practices][デザインパターン]やらパターンらしきものが出回ってるらしいじゃないですか。
.NETのアーキテクチャに[ビジネスエンティティ]という枠があるんですが、ここの実装方法について自分は良く悩みます。

型付DataSetかカスタムクラスかってとこで・・・。

もちろんTPOもあるんですが、自分的な好みはカスタムクラスなんですよね。
でも、コードを書く時間、バグの発生率等々を考えると型付DataSetみたいに自動生成を選ぶべきなんでしょうかね?
それとも、ベンダーの商品を買うべきなのか?

みなさんは、どっち派でしょうか?
(ちなみに、以外もモチありです。)

コメント(13)

typed dataset は使ったことないんですが、
永続化データにアクセスするためのプロパティ以外に、
独自のメソッドは定義出来るんでしょうか?

ビジネスエンティティってことだと、
クラスの派生属性的なものを計算するようなメソッドを
定義したくなると思うので、
カスタムクラスが良いように思います。

たとえば、商品の注文明細のレコードがあって、
それをビジネスエンティティと見たとき、
「商品名」「数量」「単価」をデータベースに
保存していたとして、小計を数量*単価で得るような
メソッドですね。

データの永続化を行う層とビジネスロジックを扱う層を
分けるかどうかの設計方針によるように思います。
一応、型付DataSet派です。

ただ、型付DataSet(typed DataSet)はあくまで自動生成なので、無理やり独自メソッドを書くことはできるけど、型付DataSetを編集して保存すると消されるというなんともいたいけな動きがちょっとげんなりしますね。
この辺、.NET 2.0のpartialですんなり解決されますが。

OOADだと、データと操作がひとつのクラスにあるのは基本だと思います。でも、DataSetを使うとそうもいかない部分も多いので、その辺はあきらめてビジネスロジックに書くようにしてます。まぁそれでうまく対処できるなら、そのようにして、フレームワークの機能を存分に使おうって感じです。
早速書き込みが来てうれしいです。

>みつじさん
永続化とビジネスロジックを分けるとかキーですか。
なるほど、確かにそうですね。自分的には、永続化とビジネスロジックは分けたいっすね。コードの量とかも多くなってしまし。

>りばてぃさん
型付っすか!!やっぱり自動生成で生産性の向上&バグの低減ですか。.NET 2.0を使ったことないんですが、何やら型付を使い易くする仕組みが増えているんですね。
型付にソースを加えるとテストとか大変じゃないですか??


マイクロソフトのサンプルアプリケーションのPetShopの内容は当てにできますかね?あれは完全にカスタムクラスで作ってるんですよね。
型付を利用してレイヤを分けるparcticesとか公開されてるんですかね?
>2: りばてぃ さん

ためになる情報をありがとうございます。
typed dataset、使ってみたくなりました。


>3: ぷち さん

ファウラー氏のPofEAAとか、パターン関係の本を読めば、
いろんな設計方針が載ってて面白いと思います。

反対意見もあるかもしれないけど、.Netフレームワークは
データ永続化に関してはOOADよりDOADに近いと
聞いたことがあります。.NetではあえてDOAD的にすることで、
Visual Studio みたいな便利なツールとライブラリの相性を
良くしてるのかなって気もします。

そういう意味では typed dataset を使うのが正統派なのかも。
カスタムクラス派です★

ASP.NETにおいて型付DataSetに書いた独自メソッドと.aspx.csに書いたメソッドの処理がかぶってしまうので。。

.NET2.0ではデータプロバイダを抽象化出来るDbProviderFactoryが気に入っているので、カスタムクラス使って書いてます。

using System.Data.Common;

string connectionName = "○○ConnectionString";
ConnectionStringSettings css = ConfigurationManager.ConnectionStrings[connectionName];
DbProviderFactory pf = DbProviderFactories.GetFactory(css.ProviderName);
DbConnection con = pf.CreateConnection();
con.ConnectionString = css.ConnectionString;
> みつじさん
ファウラー氏!あの人凄いっすね。リファクタリングの本は今読んでる最中なんですよ。(ちょい本格的に仕事で使うようになってきたんで・・・)
PofEAAですね。本屋で確認してきます。リファクタリングと表紙が似てるやつかな??

> ぴぃさん
自動で生成されると結構余分なコードも付いてきますよね。たしかに・・・。データプロバイダが抽象化できるんですか!!
ということは・・・RDBMSを意識しないでコーディングできるってことですか??
こんにちは
私はDataSetをよく使います〜
複雑な事をしたい時は、ArrayListとかをクラス化しますが滅多にしないです(笑)
そういえば、あまり構造体を使わなくなってきた気がします。。

クラスでというか、DLLにする事が多いです。
周りから、ブーイング多発です(笑)
>6: ぷち さん

PofEAAは下記です。
今では内容が古くなってるかもしれないけど
.NET(C#)のサンプルコードもあります。
http://www.amazon.co.jp/exec/obidos/tg/detail/-/books/4798105538/249-0422416-9857948

リファクタリングに表紙が似てるのはたぶんこれで、
アナリシスパターンてやつです。ちょっと上流工程向きですが。
http://www.amazon.co.jp/exec/obidos/tg/detail/-/books/4894716933/249-0422416-9857948

ちなみに私はファウラー氏の本の英語版(原書)を集めるのが
趣味です(笑)
> がちゃ。さん
ブーイングですか!?
何でブーイング食らうんですか??
めちゃくちゃ気になります。


> みつじさん

>ちなみに私はファウラー氏の本の英語版(原書)を集めるのが
>趣味です(笑)
最強ですね!!
僕も見習って勉強します。
洗礼されたコードと自動生成で作られるコード・・・。
使い分けがホント大変です。(*_*;
どっちが好きか、といわれるとWizardでサクっと作るDataSetです。

でも、OracleとかDB2とかの案件ですと結局カスタムクラスになってしまうことが多いっす。
#固定長とか、空白の扱いとか結局ADOのお世話になってしまうことも...

あとは、やり取りするデータサイズも検討するです。ナンも考えずにDataSet使うと、いい感じでメモリ食べてくれますので...

参照しかないような情報系のアプリ以外、あんまりDataSetでいい目を見たことが無いな^^;
ぷちさん。
ブーイングの理由は、「ソースが追加できない」ただそれだけみたいです。
追加・変更させないようにしてるんですけど(汗)という私個人意見は無視されます・・
悲しい限りです。
DataSetっていうのは、コレクションクラスみたいなもので、エンティティそのものではない、ってところが、いつも引っかかっています。一覧を表示するみたいな場面ではとても便利ですが、一つのオブジェクトを扱いたい、ってなると、直感的でないというか、抽象度が低いというか...
そうは言っても、DataSetは強力であることには間違いありません。
この話題は、いつも僕の中では振り子のように揺れていて、なかなか結論付けることができません。
DataSet派ですね。
ストアドは使用します。
DataReaderの併用も設計によってはします。

強力だけど弱点もある。
そんな感じですね。

>一つのオブジェクトを扱いたい、ってなると、直感的でないというか、抽象度が低いというか...
2.0はpartial class
3.0はDlinq
着実にに抽象度は上がっていきます。

ログインすると、みんなのコメントがもっと見れるよ

mixiユーザー
ログインしてコメントしよう!

.NET Framework 更新情報

.NET Frameworkのメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。

人気コミュニティランキング