ブックマーク / kmaebashi.hatenablog.com (2)

  • MVC云々の話・コードの量の問題じゃないかな - K.Maebashi's はてなブログ

    Inspired by みねこあさんとこ 発端: Life is beautiful: Ruby on Railsの「えせMVC」の弊害 Modelの外部インターフェイスの設計においてもっとも大切なことは、この「データの整合性」の責任を100%Model側で引き受け、「Controllerが何をしてもデータの整合性だけは絶対に壊れない」ように作っておくことである。 まったく同意です。 それに対するひがさんの反応: えせMVCについてそろそろ一言言っておくか - yvsu pron. yas 私は、Modelには収まりが悪いビジネスロジックはServiceにおくことをすすめています。この辺は好みで、永続化されないModelにおく方法もあります。Controllerにあったほうが良いこともあるでしょう。 まったく同意です。 「MVCとはなんぞや」的な話には実のところ興味はないのですが、私の理解

    MVC云々の話・コードの量の問題じゃないかな - K.Maebashi's はてなブログ
    pekepekesamurai
    pekepekesamurai 2009/10/20
    コード量の問題。適切な意見だと思う。結局のところ、そもそもデータを担保しない作り方=ロジックの分散を冗長するような作り方が広まっていることが問題なんだろう。
  • 業務アプリの業務部分で、オブジェクト指向なんか使わないよね - K.Maebashi's はてなブログ

    久々の更新なのでちょっとは刺激的なことを書いてみる。 今時のプログラマにはオブジェクト指向は必須、常識、みたいな言説はよく聞きます。 しかし、煽りでもなんでもなく、実のところ現場ではあまり使わない、というのも事実だったりします。 そりゃ、ライブラリやフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリやフレームワークの占める割合は大きくはない。10万行のシステムを書いて、5万行が(自社開発の)共通ライブラリやフレームワークだというのなら、それはおそらく設計が間違っています。まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか。 そして、たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの体はRDBMSにあり、それを操作するのはSQLです。よって、

    業務アプリの業務部分で、オブジェクト指向なんか使わないよね - K.Maebashi's はてなブログ
    pekepekesamurai
    pekepekesamurai 2009/04/28
    「使わない」んじゃなくて、「使えない」が大半じゃないだろうか?SQLができる云々はごもっとも。だけどOOPがちゃんと使えれば、(設計次第だけど・・・)メリットのほうがでかいと思いまふ。
  • 1