私はテーブルの行を表すクラスを持っています。行のデータを操作する関数を追加したいと思います。どこに機能を追加すればよいですか？私のメソッドはどこに行きますか
1）クラスに関連しているため、クラス内 2）別のヘルパークラスでクラス外にありますか？
これまでは常に数字1を選択していました。論理を独自のカプセル化されたクラスに分離し、データクラスの複雑さを減らすため、数字2はより良い答えと考え始めています。私は、データクラスを可能な限り裸のままにして、論理が全くないデータメンバーだけを残すべきだと考えています。
これを行うには最もアジャイルな方法は何ですか？
単一責任の原則は、「オブジェクトを変更する理由は1つだけにする必要があります」と述べられています。オプション1では、オブジェクトが変更される理由は2つあります。オブジェクトに格納されているデータを変更するか、別のデータベースシステム（たとえば、mySQL to PostgrSQL）に変更することができます。
もちろん、すべてのものと同様、トレードオフです。すべてのコードを1か所にまとめることにはいくつかの利点があります。将来別のRDBMSに切り替える可能性が低い場合は、すべてを1つのクラスにまとめるとよいでしょう。
将来的に別のデータベースに切り替えることが予想される場合や、複数のデータベースバックエンドをサポートする場合でも、別のクラスに永続性を置くほうが良いでしょう。
「アクティブなレコード」または「リポジトリ」をもっと好むかどうかによって異なります。本当に正しい答えがあるかどうかはわかりません。ちょうどあなたのコードベースには意味があります。私はまた、コードの残りの部分の設計を、一貫性が良いデザインと同じくらい重要なので、これをどのように設計するかを検討します。
純粋なMVCの意味では、ナンバー2が最適です。データモデルを作成し、すべての実装ロジックから自由にしておきます。これにより、アプリケーション間でモデルを再利用する可能性があります。コントローラは、データを操作するアプリケーション固有の実装ロジックを格納できます。
機能に依存します。クラスのポイントは、一般的に関数とデータをカプセル化することです。
関数が行クラスに保持されているデータ型に固有で、行クラスが一般的な場合は、その行からサブクラス化して関数をスティックすることができます。
ヘルパークラスはクラスの複雑さを解消するのに便利ですが、ヘルパーとクラスの役割が明確に定義されていることを確認して、今後のメンテナンスでその契約を泥沼にしないようにする必要があります。
正解は「それは依存する」です。 「行内のデータを操作する」は、どちらの答えにも正当性があります。
懸念の分離という点では、この関数がどのような抽象関数を操作するかを特定する必要があります。それはデータベースの行の抽象化ですか？そのクラスに入れてください。データベースの行に関して実装されているデータモデル内のオブジェクトですか？そのクラスに入れてください。
より一般的に言えば、関数を適用する抽象レベルに配置する必要があります。これは、全体のデザインに非常に依存します。
再利用可能なフレームワークを開発している場合を除き、データベースシステムの変更について心配する必要はありません。ほとんどのアプリケーションはデータベースシステムの変更を終わらせることはありません。したがって、これは通常無駄な作業です。 もちろん、他の人が予期せぬ環境で使用する再利用可能なフレームワークを使用している場合は、この実装に時間を費やすのが理にかなっています。 –
そして、あなたが（私たちに起きた）ことを期待していないときに、データベースシステムを変更しなければならないことがあります。しかし、それはあなたが必要とするときにのみ対処すべきものです。それがまだ必要でなければ複雑さを乗り越える価値はありません。 –