C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

掲示板トップ C# と VB.NET 入門 新規作成 利用方法 ツリー表示 トピック表示 ランキング 記事検索 過去ログ
ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

全過去ログを検索

<< 0 >>
■6417 　関数呼び出しの際のオーバーヘッドに関して
□投稿者/ yagiey -(2007/08/10(Fri) 13:33:19)

    分類:[C#]　

    C#における、関数呼び出しの際のオーバーヘッドに関して質問させていただきます。

    例として、System.Windows.Formsを継承したMyFormクラスについて考えます。
    MyFormのLoadのタイミングで何かやろうとする場合、一般には以下の方法があるかと思います。
    （リフレクションは考えないこととします）
    1. OnLoadメソッドのオーバーライド
    2. Loadイベントハンドラを定義して、Loadイベントにアタッチ

    1と2のうちどちらが実行時のコストが小さくて済むのでしょうか？
    私の感覚としては、

    1の場合：
    動的ポリモーフィズムを前提にしている（仮想関数を用いている）という時点でそれなりにコストがかかる。
    （仮想関数テーブルに相当するものがあるのか知らんけど...。）

    2の場合：
    Loadイベントに登録するハンドラをMyForm_Loadとします。
    MyForm_LoadはFormのOnLoadで呼ばれることになりますよね（推測）。
    となると、1の場合のコストに加えて、「デリゲートによるイベントハンドラの実行」というコストがかかってしまう。

    ということで、「1の方がコストが小さくて済む」というのが私の結論です。
    皆さんの意見をお聞かせ頂ければ、うれしく思います。
親記事 /過去ログ17より / 関連記事表示
削除チェック/

■40767 　★2009/11/07 東京のスピーカー募集
□投稿者/ 中博俊 ＠ -(2009/09/02(Wed) 13:53:28)
>

    分類:[.NET 全般]　


    なかです。

    11/07のわんくま東京勉強会のスピーカーを募集します。
    最近は勉強会で次の勉強会のスピーカー募集することが多いですが・・・・

    11/7ほかのネタは

    ・着物
    ・デバッグ
    ・データベース

    何かがありそうです。

    ネタはなんでもOK＜技術ネタである必要すらありません。

    ぜひ立候補をお願いします。
    #残念ながら全員にお願いできないかもしれませんが、そこのところはよろしくお願いします。mm
親記事 /過去ログ70より / 関連記事表示
削除チェック/

■69247 　Re[3]: Type.GetProperties時の構造体判別
□投稿者/ DD. -(2013/12/11(Wed) 09:07:11)
    お世話になります。DD.です。

    お二方に回答頂いた内容で、構造体の判別ができました。
    ありがとうございます。

    解決済とさせてもらいます。
記事No.69236 のレス / END /過去ログ118より / 関連記事表示
削除チェック/

■86720 　Re[1]: oo4oからodp.netへの変換
□投稿者/ 魔界の仮面弁士 -(2018/03/02(Fri) 22:34:30)
    2018/03/02(Fri) 22:41:49 編集(投稿者)

    ■No86717 (yuuki さん) に返信
    > VB6⇒VB.NETへのコンバージョンについてご相談させていただきます。

    WinForm への画面表示や編集(DataGridView等)を伴うなら、
    　1: System.Data.OracleClient 名前空間
    　2: Oracle.DataAccess 名前空間
    　3: Oracle.ManagedDataAccess 名前空間
    のいずれかを用いて、DataSet を通じて編集・更新することが多いです。
    （3 を推奨 / 1 は非推奨）


    一方、集計処理やバッチ処理といったものであれば、DataSet はあまり使われず、
    DataReader と Command を使う機会が増えます。


    > データベースアクセスがoo4oからodp.netへ変換しないといけません。
    ODP.NET / ADO.NET は、『非接続型』というアプローチを取っています。下記参照。
    http://otndnld.oracle.co.jp/easy/dotnet/oo4otoodp/

    その意味において、ODP.NET(あるいは ADO.NET)の設計思想に近いのは
    oo4o よりもむしろ ADODB の方です。

    DataSet / DataTable および DataAdapter を通じた取得と更新という考え方は、
    ADODB の「オフライン Recordset」「リシェイプ」「バッチ更新モード」に
    近いところがあるのですが、oo4o には該当する機能が無かったはず…。


    > odp.netのクラスに機械的に変換すれば全く可能であることはわかっているのですが、
    ODP.NET には、OO4O の「編集可能な OraDynaset」に該当する物がありません。

    ODP.NET/ADO.NET で DataSet を通じてバッチ更新する処理は、
    オプティミスティックな更新となります。


    > OraDynaset　⇒　OracleDataReader
    「DataReader」の文字通り、これは ORADYN_READONLY かつ ORADYN_NOCACHE な OraDynaset に相当するものです。
    OracleDataReader を通じて AddNew/Edit/Update することはできないのでご注意ください。


    > ラッピングクラスを作成すれば、
    個人的には、ラッピングはあまりお奨めしていません。

    RDO / DAO / ADODB / OO4O の場合は、アーキテクチャが似ているので
    相互にラッピングしやすいですが、 ODP.NET / ADO.NET のアーキテクチャは
    OO4O のものとは考え方が異なるので、差異を把握した上で実装しないと
    VB6 時代の作られ方に引きずられることになってしまい、
    ODP.NET / ADO.NET らしい書き方を阻害してしまう危険性があるためです。

    たとえば、DataAdapter や TableAdapter は、ODP.NET / ADO.NET で良く使われるものであり、
    VB6 で言う所の DataEnvironment に相当する機能と言えるのですが、
    oo4o にはこれに相当する機能が無いため、もしもラッピングするのであれば、
    本来の機能を阻害することがないようなクラス設計を施さねばなりません。


    それゆえ個人的には、ラッピングして処理を内包してしまうのではなく、
    基本的には ODP.NET をそのまま用い、それを手助けするためのヘルパーを用意したり、
    拡張メソッドで互換機能を構築することをお奨めしておきます。


    なお、拡張メソッドで ADO.NET / ODP.NET を機能拡張するという手法は、
    System.Data.Linq 名前空間や Dapper 名前空間などで採用されています。


    > OraSessionClass　⇒　OracleConnection
    > OraDatabase　⇒　OracleConnection
    ODP.NET はコネクションプーリングが既定で有効になっているので、
    この部分はまとめてしまっても問題は無さそうです。

    ただ、OraSessionClass での BeginTrans と
    OraDatabase での BeginTrans を区別している場合には
    トランザクションの管理単位を見直す必要があるかもしれません。


    > OraSessionClassとOraDatabaseは何となく想像がつくのですが、OraDynasetのFields辺りのデータ取得の部分のイメージがわかないです。
    OracleDataReader からだと、Item プロパティ や Get型名 メソッドあたり。

    DataSet / DataTable からだと、DataRow クラス の
    ItemArray プロパティ / Item プロパティ、Field(Of ) 拡張メソッド / SetField(Of ) 拡張メソッド。
    DataViewRow の場合は、そのままインデクサでアクセスすれば OK。

    データではなく列情報のことだとしたら DataTable の Columns プロパティが相当しますが、
    これは Oracle 側の型情報ではなく.NET 側に取り込んだ後の情報となります。
    サーバー側のスキーマを得たい場合は OracleDataReader の GetSchemaTable メソッドか
    OracleConnection の GetSchema メソッドで得ることができます。
記事No.86717 のレス /過去ログ149より / 関連記事表示
削除チェック/

■86728 　Re[2]: oo4oからodp.netへの変換
□投稿者/ yuuki -(2018/03/05(Mon) 14:07:17)
    ■No86720 (魔界の仮面弁士 さん) に返信
    魔界の仮面弁士 様

    ご返答ありがとうございます。
    非常に貴重な意見を頂いたと思っております。
    （ちなみに以前にも魔界の仮面弁士様にはご助力いただいた者です）

    拡張メソッドですか。なるほど、そこの発想は少しありませんでした。

    そもそも、今回ラッピングクラスを考えたのは、
    現状２００機能ほどある、oo4oを使用した機能はDBアクセスは至極単純なものになっており、
    そのほとんどが
    ■データ取得
    OraDatabase.CreateDynaset(sql_str, ORADYN_READONLY)
    ⇒.Fields(1).Valueで値参照
    ■データ更新系
    stringにDMLを作成
    ⇒OraDatabase.ExecuteSQLで実行
    といった形で形成されています。

    その一つ一つをodp.net用に作り替えるより、ラッピングクラス作ったほうが、ソース自体はほぼ変更しなくて楽じゃないかな。。と思った次第であります。

    質問の記載から、色々ネットで調べてみたところ、やっぱり同じような考えをしている方がいらっしゃいました。
    https://takanosho.wordpress.com/2015/12/22/vb-advent-2015/
    http://kozhouse.homeip.net/dotnet/oo4o/

    機能限定すれば、なんとなくラッピングしたほうが楽な気がしました。
    ご指摘のADO.NETの件についても視野にいれて考えてみたいと思います。
    ただ、ADO.NETはデータソースへの接続にブリッジが入るのが少し気になるところ。。

    >OracleDataReader からだと、Item プロパティ や Get型名 メソッドあたり。

    >DataSet / DataTable からだと、DataRow クラス の
    >ItemArray プロパティ / Item プロパティ、Field(Of ) 拡張メソッド / SetField(Of ) 拡張メソッド。
    >DataViewRow の場合は、そのままインデクサでアクセスすれば OK。

    なるほど、なんとなく理解できました。
    個人的にどこまでやれるかちょっと挑戦してみたくなりました。
    貴重な情報、ありがとうございました。
    また、何かお気づきの点があればご教授ください。

    よろしくおねがいいたします。
記事No.86717 のレス /過去ログ149より / 関連記事表示
削除チェック/



<< 0 >>
パスワード/

- Child Tree -