ActiveObjects - 萌えキャラですね、わかります萌えキャラですね、わかります 自分のメモ用Wiki トップページページ一覧メンバー編集 ActiveObjects 最終更新： himachoco 2009年06月17日(水) 21:06:29履歴 Tweet ActiveObjects おためし#1 ActiveObjects おためし#2 ActiveObjects おためし#3 ActiveObjects おためし#4 AO#5 Schema Generation AO#6 Name Converter
pythonのORMを色々試してみた – taichino.com
そろそろpythonでもSQLを直に書くのが面倒になってきたので、O/Rマッパーを探してみたところ、幾つか種類があったので有名どころを使ってみることにしました。今回試したのは以下の4つです。 SQLAlchemy SQLObject Elixir Storm まず用途についてですが、僕はテーブルスキーマはSQLで直に書きますので、ORMでDDLを扱うつもりはありません。DMLを簡単に扱いたいというのが一番の目標です。そこで予め作成して置いたテーブルに対してCRUD操作のし易さを比べてみました。比較に使用したのは以下のテーブルです。 CREATE TABLE `books` ( `id` int(11) NOT NULL AUTO_INCREMENT, `title` varchar(100) DEFAULT NULL, `price` int(11) DEFAULT NULL, `isbn
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
syboos.jp
