はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

[gomi_ningen]

“上記のような疎にするために余計なレイヤを挟むアーキテクチャよりも、ERモデルを直にモデルにするのでも良いのではないかと思うことが最近は多い。上記のような構成は、レイヤ間の疎結合を実現するために、無駄な

[unagii_nu]

“上記のような疎にするために余計なレイヤを挟むアーキテクチャよりも、ERモデルを直にモデルにするのでも良いのではないかと思うことが最近は多い。上記のような構成は、レイヤ間の疎結合を実現するために、無駄な

[webmarksjp]

プログラミング

[ockeghem]

↓id:Kanatoko MySQLのソース変更して、unionをonionにしてしまう方が異端ww ところでOnion Unionてあるのね。いつも心にタマネギを

[t_yano]

もちろん悪じゃない。Javaですら、Cayenneとか普通にエンティティをそのままモデルとして使います。

[stonife]

あまりに疎すぎて、後続の開発者がその意図を理解できなくてぐだぐだになってるコードをよく見たなぁ

[GegegeMokeke]

多層構造は開発コスト高いよね・・・DTOを少なくすると多層にしても依存でるし、1レイヤーしか飛び越えないようにすると無駄にクラスの数増えるし・・・SQL直接打たせろ！って思う状況も多いし　フムフムなエントリ

[shinfukui]

modelをpersistenceへのboundaryとしても扱うことの是非についてかな？ アリだと思います。DB層はめったに変わらないので。変わる時はModelも一緒に変わる事が多いし。それより頻繁に変わるUI側との分離をもっと積極的に。

[kazeburo]

domain model

[oinume]

自分もrailsl派だなぁ。Controller層から直接Model扱ったほうが直感的でわかりやすいし、何をやっているのか一目でわかる。

[terazzo]

(主にJavaの話だけど)メタデータとデータの中身をオブジェクトという一つの入れ物で扱ってるのが余分な手間を生んでいる気がする。あと最近の高度化したO/Rマッパは実はロジック層なのでセーフという理屈も考えた。

[koma-tak]

『レイヤ間の疎結合を実現するために、無駄なコストを払いすぎているんじゃないか』

[charsbar]

Catalystとしては悪。一般的なフレームワークとしては悪とは限らない。要するにメタの状態で考えるか、Catベースの独自フレームワークとしてとらえるかの違い。ただ、Catは常にMaypoleとの対比を考える必要はある

[nihen]

自分もこういう認識ではいた。けど悩んでた。うーん