- PR -

共通ライブラリクラスについて

«前のページへ 1|2|3|4|5|6|7 次のページへ»
投稿者投稿内容
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-04-29 16:18
Jittaさん、囚人さん、じゃんぬねっとさんのおかげで、何となく DLL の分け方が
わかってきたような気がします。

＃僕は、PGスキルは、わんくま同盟さんによって支えられていたのですね・・・

とりあえず、R.Tanaka.Ichiro 一本にまとめていたものを

R.Tanaka.Ichiro
R.Tanaka.Ichiro.Windows.Forms
R.Tanaka.Ichiro.Data

にしてみました。

まあ、R.Tanaka.Ichiro が３つに分かれたところで、皆さんには関心が無いかもし
れませんが、分け方としては、多分これで良いんじゃないかと。

＃@IT が軽い日は、ちょっと悲しい・・・重いのも悲しいけど。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2006-04-30 10:20
引用:

じゃんぬねっとさんの書き込み (2006-04-29 13:38) より:

引用:

・商品マスター
・取引先マスター
・発注機能
・売上機能
・売上集計機能
・入金管理機能

これだけでは利用範囲が明確でないので、お答えできませーん。
が、正解だと思います。(^^)

先越された。。。


2006-04-27 22:37 に書いたことですが、機能を列挙しただけなら、「時と場合による」という答えになると思います。「こういう開発形態で、このようなことに留意して開発を行うとき」と聞かれると、どうなるか決められると思います。


　まぁ、今までの経験から。。。

　データベースアクセスで、まず１アセンブリ。共通して使えそうなビジネスロジック、たとえば入力の妥当性検証ですね、それに１アセンブリ。←プログラムの著作権云々対策でもある。
　マスタテーブルを、まとめて１つの DataSet として宣言するかどうか。これが今の悩みどころ。
　おそらく、機能ごとに別々の人が担当することになるだろうから、機能ごとに１アセンブリ。
　ただし、それぞれでバラバラな UI を実装されたらかなわないので、Form の継承元になるようなアセンブリを用意するかもしれない。
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-05-01 10:14
引用:

Jittaさんの書き込み (2006-04-30 10:20) より:

2006-04-27 22:37 に書いたことですが、機能を列挙しただけなら、「時と場合による」という答えになると思います。「こういう開発形態で、このようなことに留意して開発を行うとき」と聞かれると、どうなるか決められると思います。


そうですね。質問が曖昧でした。
しかし、答えられない理由が理解できた時点で、どのように分けるべきか？、も理解
できました。
また「今までの経験から・・・」の部分も、とても参考になりました。
ありがとうございました。

この中で何点か更にご教示いただきたい部分があるのですが・・・
重ね重ね申し訳ありません。

引用:

Jittaさんの書き込み (2006-04-30 10:20) より:

　データベースアクセスで、まず１アセンブリ。共通して使えそうなビジネスロジック、たとえば入力の妥当性検証ですね、それに１アセンブリ。←プログラムの著作権云々対策でもある。


これは、受託開発(ソースコードでの納品)の時に、自社の資産をソースコードで渡
したくない場合に DLL レベルで納品できると言う事でしょうか？
いや、過去にそういうことをしたことがあって、こういう場合、皆さんどうしているのかなーなんて・・・(^^;

引用:

Jittaさんの書き込み (2006-04-30 10:20) より:

マスタテーブルを、まとめて１つの DataSet として宣言するかどうか。これが今の悩みどころ。


DataSet は最近使い始めて勉強中なんですが(今までは都度 Reader を使っていまし
た）、細かく分けた場合と、例えばひとつにまとめた場合のメリット、デメリットが
よくわかりません。
今のところ、一つにまとめて使う方法をとっているのですが、上記引用部の記述で
「これはいけないことなんだろうか？」などと思い始めてます。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-05-01 10:46
引用:

Ｒ・田中一郎さんの書き込み (2006-05-01 10:14) より:

DataSet は最近使い始めて勉強中なんですが(今までは都度 Reader を使っていまし
た）、細かく分けた場合と、例えばひとつにまとめた場合のメリット、デメリットが
よくわかりません。
今のところ、一つにまとめて使う方法をとっているのですが、上記引用部の記述で
「これはいけないことなんだろうか？」などと思い始めてます。

型を考えるとまとめてより、個々に持つのが良いと思います。
ただ、工数の問題もありますし、未来永劫使うわけではないという場面が多いですからね...

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-05-01 12:56
引用:

マスタテーブルを、まとめて１つの DataSet として宣言するかどうか。これが今の悩みどころ。

引用:

今のところ、一つにまとめて使う方法をとっているのですが、上記引用部の記述で
「これはいけないことなんだろうか？」などと思い始めてます。

型付 DataSet の話をしているという前提で。

確かにこれは悩みどころですね。DataTable 一つで事足りるものが多い時は尚更まとめてしまおうかと思います。
私は「分ける方」に一票。

田中さんの例を使うと「発注テーブル」「発注明細テーブル」で一つの DataSet 。場合によっては、これに「商品テーブル」も追加。
商品データだけを触る時は「商品テーブル」のみを含んだ DataSet 。
つまり、リレーションシップを貼れるものでまとめるという感じです。

しかし、これだと、各 DataSet の「商品テーブル」が別のテーブルとして扱われるのが厄介。同様のスキーマを管理するのが煩雑だ。
_________________
囚人のジレンマな日々
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2006-05-01 21:56
引用:

Ｒ・田中一郎さんの書き込み (2006-05-01 10:14) より:

これは、受託開発(ソースコードでの納品)の時に、自社の資産をソースコードで渡
したくない場合に DLL レベルで納品できると言う事でしょうか？
いや、過去にそういうことをしたことがあって、こういう場合、皆さんどうしているのかなーなんて・・・(^^;

　私が関わったのは、たいてい一から作ってそこ専用なので、本当に対策したことはないのですが。。。
　たとえば、帳票管理で、ほぼすべての項目によって、任意の条件で検索したい、、、ということは、よくあると思います。ここでも、「Where 句を組み立てたい」という質問を、何件か見ています。この、「組み立てる方法」は、マイ・フレームワーク化できるところではないかと思います。


引用:

DataSet は最近使い始めて勉強中なんですが(今までは都度 Reader を使っていまし
た）、細かく分けた場合と、例えばひとつにまとめた場合のメリット、デメリットが
よくわかりません。
今のところ、一つにまとめて使う方法をとっているのですが、上記引用部の記述で
「これはいけないことなんだろうか？」などと思い始めてます。

　.NET の案件は、実は１つしかこなしていなくて、それのバージョンアップがずっと続いています。で、今回、そのシステムがよそで使っていただけることになったのですが。。。良かったと悪かったが、半分半分といったところでしょうか。
　最初に、使う方法がかっちり決まっていれば、悪くはないと思います。
　しかし、同じもので違うことをしようとしたり、同じことを表す違う表現のデータを扱おうとすると、身動きしづらくなります。
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-05-02 11:44
引用:
じゃんぬねっとさんの書き込み (2006-05-01 10:46) より:

型を考えるとまとめてより、個々に持つのが良いと思います。
ただ、工数の問題もありますし、未来永劫使うわけではないという場面が多いですからね...


そうなんですよね。
現時点では、DataSet(型付)の勉強中で、コードも自動的に吐き出されたものを使用
しているということもあり、まとめてしまう場合が多いのです。
（いろいろ使い初めてみると、後からのメンテナンスも考えて、自分で書くことに
なりそうなんですけど）
皆さんのお話を聞いていると、まとめておいて必要に応じて分けても良いかな〜、
なんて思い始めてます。

「計画通り！」には中々いかないようです。
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-05-02 11:49
引用:

囚人さんの書き込み (2006-05-01 12:56) より:

型付 DataSet の話をしているという前提で。


そうでした。すみません。
型付DataSet の場合です。

引用:

囚人さんの書き込み (2006-05-01 12:56) より:

私は「分ける方」に一票。

田中さんの例を使うと「発注テーブル」「発注明細テーブル」で一つの DataSet 。場合によっては、これに「商品テーブル」も追加。
商品データだけを触る時は「商品テーブル」のみを含んだ DataSet 。
つまり、リレーションシップを貼れるものでまとめるという感じです。


そうですね。
この方がすっきり分けられて理想的ですね。

引用:

囚人さんの書き込み (2006-05-01 12:56) より:

しかし、これだと、各 DataSet の「商品テーブル」が別のテーブルとして扱われるのが厄介。同様のスキーマを管理するのが煩雑だ。

迷いは続くのですね。
«前のページへ 1|2|3|4|5|6|7 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）