「ビジネスロジック」とは何か、どう実装するのか - Qiita
アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い
Repositoryパターンのアンチパターン - Qiita
よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ
Repositoryパターンにおける、MVC + Service + Repositoryの役割をもう一回整理してみる
Repositoryパターンにおける、MVC + Service + Repositoryの役割をもう一回整理してみる 最近いろんな技術書を読み始めたり、コード設計的なところを調べてみたりして、 ふわっとなんとなく使っているRepositoryパターンにおける「Model」「View」「Controller」「Service」「Repository」のそれぞれの役割についてもう一回整理してみました。 役割をきちんと分かっていないと、形だけのRepositoryパターンになってしまいきれいなコードが書けなくなってしまいます。 というわけで、れっつごー！ Viewはユーザーと直接触れ合う場所 Viewは役割がわかりやすいので今更書かなくても、、と思ったのですが、一応。 Viewは「画面の表示」「画面表示のための判断・処理」を行う場所です。 LaravelだとbladeやVueやReactなどが
MVC の Model 肥大化への対処 - Qiita
MVC とは何かを 1 から学ぶ で投稿した内容の続きとして、MVC の問題点についてどう対処するか、についてまとめていきます。 MVCの問題点 (再掲) 業務で扱うデータ要件が複雑になればなるほど、Model が肥大化していく (今回のテーマ) 入力に応じた出力要件が複雑になればなるほど、Controller と View の依存性が高くなる Model の肥大化とは… 例えば、Issue 管理のための Web アプリケーションを作成するとします。 Web の画面から、ユーザが Issue を閲覧・登録・更新・削除出来るようにする場合、以下の実装を担当するのはどこでしょうか。 DB に格納された Issue から、未完了のものを取得する ユーザが更新 / 削除するために選択した Issue の詳細情報を取得する ユーザが更新 / 削除するために選択した Issue が完了済でないかチェッ
MVCパターン再考 - Qiita
背景 Java, Groovy, C++, C#などいろいろな言語使ってアプリケーションを作成するなかで、MVCパターンを常に意識して開発してきました。 自分的な解釈だと、上記のような大雑把の分類です。 Model: ビジネスロジック、データベース処理、データオブジェクトなど View: 画面出力 Controller: ViewとModelの仲介役、ユーザーの入力をModelに渡すなど しかし、あるセミナーで「ネイティブアプリでは、MVCは合わない」という話を聞き、改めて、MVCがどこまで適用できるものなのか、そもそもMVCってなんだろう？と再考したくなりました。というわけで、MVCModelを再考してみます。 MVCと一言で言っても・・・ 改めて調べて分かったのですが、一口にMVCといっても、以下、分類があることがわかりました MVC1 MVC2 Pull-MVC Push-MVC M
列車画像をポスターに無断使用 東武鉄道子会社に撮影男性へ賠償命令（朝日新聞デジタル） - Yahoo!ニュース
列車の画像を東武鉄道（東京）のポスターに無断で使われて著作権を侵害されたとして、埼玉県の30代男性が同社などに計125万円の損害賠償を求めた訴訟の判決が8日、さいたま地裁であった。倉沢守春裁判長は画像が無断で使われたと認め、ポスターを作製した同社の子会社「東武ステーションサービス」（同）に50万円の支払いを命じた。東武鉄道への請求は「監督すべき義務があるというのは困難」などとして棄却した。 【写真】問題となったポスター=読者提供 問題になったのは、側面から撮影した東武鉄道の列車「SL大樹」「DL大樹」「スペーシア」「日光・きぬがわ」「リバティ」などの画像を、先頭から最後尾までの全車両が1枚に収まるように加工したもの。 判決によると、画像は男性が撮影、加工し、自身のWEBサイトで公開していた。東武ステーションサービスは2020年10月ごろ、これらの画像7点を男性に無断で使い、ポスターを作製。
Seleniumを用いたTwitterへのログイン及び投稿 - Qiita
本稿の趣旨 カレン氏は激怒した。必ず，かのAPIを除かなければならぬと決意した。カレンにはTwitterがわからぬ。カレンは，SpaceXのCEOである。ほらを吹き，ドローンと遊んで暮して来た。けれども金儲けに対しては，人一倍に敏感であった。 なぜTwitter APIを使わないか Twitter API利用のためには，Botの製作意図などを書面でTwitter Devへ申請する必要があります。この作業が不透明で，私など過去に申請したところ「価値なし！」と一蹴され，アク禁まで食らって何年も放置されました。このような事例は多数あるらしく，Seleniumを用いてWebブラウザアクセスを装い，Twitterを操作する方法が試されてきました。この度，スペース・カレン氏がTwitterを買収したタイミングで私のアク禁は解除されたものの，APIアクセスの申請などしようものなら「NOT "GOOD"
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
