- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
8 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:10:07.53 ID:QnX5sSrT - 設計なんで実装の話は原則禁止
どの言語でも通用する話をするべき
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
9 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:10:37.66 ID:QnX5sSrT - >>4
設計の話なんで、ExcelとかSQLとか言う話はいらない。
抽象化して書いてくれ
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
10 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:18:03.15 ID:QnX5sSrT - いや俺が書いてあげよう。ExcelやSQLという言葉を消すだけだが
・「マイグレーションファイルに記述した定義から
いろんなデータベースにスキーマと初期データを自動生成する。
このフレームワークは初期データファイルから
データの流し込みを行ってくれる
スキーマや制約も出来る限り
頑張って設定してくれる。(わからない場合デフォルトの名前とか
が入るようになる。)
オプション指定機能が搭載されていて、
オプション次第で多くのDBMSに対応できる。
ER図とかの自動生成機能も存在する」
つまりRailsのようなものだ。
Railsを設計してくれという話だ。
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
12 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:24:44.32 ID:QnX5sSrT - つまりは>>4はActiveRecordの設計がどうなっているか？
ORMとはどのような設計になっているかという話がしたいということだろう。
ORMとはデータベースをオブジェクトにマッピングしてくれるものだ。
というのはよく言われる簡単な説明の一つだな。
まず二次元のデータベースっていうのは慣れると単純なので
ある意味楽ではあるが、現実世界は二次元のデータには収まらない
初心者が勘違いしてしまうのはORMは単なるSQL生成ツールだと
思ってしまうこと。まあそれは本当の初心者だろうが、
ORMは複数のテーブルがあってそれぞれがつながってる
データベース全体をオブジェクトの形で表現するもの。
テーブル＝モデルと考えてしまうと、ある地点で行き詰まってしまう。
データベース＝モデル群と考えるのが正解。
データベースに入っているデータをいろんな視点（＝モデル）から
見ることができるようにするのがORM
だからORMを使う時にモデルとモデルのつながりの定義を書くのは必須なのである
（もちろんログや設定のようなつながりを持たないモデルもあるにはあるが）
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
13 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:25:13.78 ID:QnX5sSrT - >>11
設計の話なんで要件の話はいらない。
設計の話をしましょう。
ActiveRecordとかね
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
14 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:29:12.39 ID:QnX5sSrT - ActiveRecordはRailsが有名になったせいで
Rails特有のライブラリや概念だと勘違いしている人も
いるかもしれないがそれは違う。
ぐぐればすぐに分かることだが
http://www.techscore.com/tech/Ruby/Rails/other/designpattern/1/
> 1. Active Recordパターンとは？
>
> Martin Fowler氏の Patterns of Enterprise Application Architecture （邦訳）で
> 解説されているデザインパターンのひとつで、以下のように解説されています。
>
> データベーステーブルまたはビューの行をラップし、データベースアクセスを
> カプセル化してデータにドメインロジックを追加するオブジェクト
日本語訳は残念との噂が高いが、この本のこと
エンタープライズアプリケーションアーキテクチャパターン
https://www.amazon.co.jp/dp/B01B5MX2O2
なのでActiveRecordパターンの話は
あきらかに設計思想の話であると明確にしておこう
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
16 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:33:41.73 ID:QnX5sSrT - ActiveRecordパターン等のパーシステンス層アーキテクチャパターン
には次のようなものが有る
http://otndnld.oracle.co.jp/columns/arai-semi/data_access/2/
> Table Data Gateway
> Row Data Gateway
> Active Record
> Data Mapper
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
17 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:35:53.60 ID:QnX5sSrT - >>15
> Excelは排除したくない。
お前の都合は知らん。
一番シンプルでわかりやすく強力な手段を選ぶべき
例えば、booleanと書けばいいのに真偽値と日本語で書くようなもの。
not null と書けばいいのに必須と日本語で書くようなことに意味はない
その考えで行くとExcelは排除すべきという結論になる
そのことを説明してもいいが、そもそも設計の話とは無関係なので
Excelの話はここでもう終わり
お前風言うのであれば
「Excelは排除したい」だ。このスレから
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
19 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:37:47.81 ID:QnX5sSrT - 一人で設計とは関係ないエクセルがーって
話をしたいならどうぞご勝手にとしか言うつもりはない。
ただ設計思想とは全く関係ないということだ。
だから設計思想の話をしたいと思ってる人は
俺を始め、エクセルの話は誰もしないということは受け入れろ。
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
20 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:38:23.39 ID:QnX5sSrT - >>18
> 仕様が確定してれば設計なんて猿でもできる
それができる猿は見たこと無いので
説得力ゼロだよ。
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
21 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:40:19.76 ID:QnX5sSrT - 設計思想の話に戻ろう
といっても俺が何やら言うよりもまずはコピペでいいあろう。
設計思想の話について、何か意見があればどうぞということだ。
Active Record
３つ目はActive Recordです。一言で言うと「データベースのテーブル/ビューの
１つの行をラップしたオブジェクトで、データアクセスロジックやドメインロジックを
カプセル化したオブジェクトとして実装」といえるかと思います。
Active Recordは、それ自身にドメインロジックを含むという点でドメイン層の
Domain Modelパターンとデータベースのテーブルのレコードを表すという点で
パーシステンス層のRow Data Gatewayパターンに良く似ています。
まず、Domain Modelと似ているという点ですが、Active Record自体が
Domain Objectと成り得るのですが、本当？のDomain Objectと異なる点は、
Active Recordはテーブルの構造を元にして基本的にテーブルの列の表現として設計される点です。
一方、Domain Objectは、テーブルの構造に関係なく、オブジェクト指向のドメイン分析の結果抽出されます。
例えば、前編で説明したDomain Modelでは、Strategyパターンを利用しているものの、
BIDテーブルに対応したBidクラス、Itemテーブルに対応したItemクラス、
SALEテーブルに対応したSaleクラスとテーブルとクラスがほぼ一対一になっていますが、
ドメインオブジェクトの設計によっては同じテーブル構造のまま、Itemを抽象クラスとして用意して、
そのItemを継承したBookやComputerなどの具象クラスを作成する様な継承関係を実装するかもしれません。
その場合、それら継承関係をItemテーブルという１つのテーブルに格納しなければならないかも知れません。
つまり、Domain Modelが複雑になればなるほど、両者の違いは明確になってきます。
そもそもドメイン層とパーシステンス層という全く役割の異なった層のパターンですので違うのが当たり前ですが・・・
あと、Row Data Gatewayと似ているという点ですが、これは単純にActive Recordがドメインロジックを含むという点かと思われます。
Active Recordパターンのコードは、Row Data Gatewayとほぼ同じです。異なる点は、
それ自身にドメインロジックが含まれるという点ですので今回は省略します。
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
22 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:44:51.15 ID:QnX5sSrT - パーシステンス層アーキテクチャパターンの選択
それでは、どのパーシステンス層のアーキテクチャパターンを選択すべきでしょうか？
これは、ドメイン層のアーキテクチャパターンの選択に大きく依存します。PoEAAでは、以下の様な組み合が考えられるとしています。
ドメイン層アーキテクチャパターン パーシステンス層アーキテクチャパターン
Transaction Scriptパターン Row Data Gatewayパターン
Table Data Gatewayパターン
Domain Modelパターン Active Recordパターン
Data Mapperパターン
Table Moduleパターン Table Data Gatewayパターン
ドメイン層とパーシステンス層はどの様な組み合わせでもかまいませんが、
より合わせやすいパターンは上記の様な組み合わせといっています。
また、少し視点を変えて各アーキテクチャパターンとシステムの論理的な階層の依存関係を表すと以下のように成るかと思われます。
【図】パーシステンス層/ドメイン層アーキテクチャパターンの依存関係
かなり抽象的かつ感覚的な図ですので、大体の感触をつかんでいただければ良いのですが、
１つ言えることは、システムの論理的な階層である、ドメイン層とパーシステンス層は、
其々異なる役割を持った層ですので、お互いに依存が少ないほうが好ましいと思われます。
その点で言うとDomain ModelとData Mapperがお互いの層で依存関係が少なく済みます。
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
23 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:49:06.93 ID:QnX5sSrT - >>22に自己レス
パターンはぶっちゃけどれもまともに使っていれば悪くないんだろうけど
結局は使うフレームワークによるよな。
ウェブのシステムは単純なのが多いから
トランザクションスクリプトパターン使って
テーブルデータゲートウェイかな？
SQLを生成してくれるライブラリで十分だと思っているけど、
Rails使ってみるとアクティブレコードパターンよく出来てるんだよな。
これぐらい作り込まれていれば、ドメインモデルパターンもやる気になる
（流石に貧弱なフレームワークでドメインモデルは大変すぎた）
|
- 設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
26 ：デフォルトの名無しさん[sage]：2017/09/29(金) 23:58:13.22 ID:QnX5sSrT - >>24
エクセルはただファイルフォーマットにすぎない。
設計思想とは何の関係もない。
ファイルフォーマットとしてみれば
無駄に重く二次元に縛られてるから柔軟性がない。
YAML形式のほうが遥かに可読性が高くて
柔軟性が有るファイルフォーマット
ってかファイルフォーマットの話はいらない。
|