最初に、私の経験は、ORM を既に提供しているリッチ Web フレームワークである Django での経験です。オブジェクトを表すモデルを作成する必要があります。私は生のSQLを実行しません。
したがって、当然、2番目のアプローチをお勧めします。すぐに、3番目のアプローチは頭痛の種になると思います。なんで?さまざまな後処理を行う必要があるためです。それがゲームの性質です。Web 上に CRUD インターフェースを配置すると、ユーザーが CRUD ページから認識できないものもいくつかフィールドとしてモデルに保存されます。例として、さまざまな企業が関連付けられているニュース記事の CRUD ページがあります。(これはデータベースの外部キーです。) 当然、これはログイン情報によって自動的に提供されます。ただし、Web ページにログインするプロセス (およびそのログインが保存される場所) は、リモート API の場合とは大きく異なります。
私の好みは、最初の 2 つのアプローチを少し組み合わせることです。オブジェクトが保存されるたびに発生するアクションが必ずあるはずです。それらをsave()
メソッドに入れます(またはupdate()
、insert()
もう少し細かくしたい場合)。この機能を 2 回実装することを考えるべきではありません。
ただし、Web インターフェイスとリモート API では、逆シリアル化/オブジェクトの構築と検証が異なる方法で行われます。これは本当に個別に実装する必要があります。
また、バリデーションをデシリアライゼーションとは本質的に異なるものと見なし、一部のルールは同じで他のルールは異なると考えるかもしれません。たとえば、Web インターフェースでは、ストーリーを受け取ったときにmodification_time
自分自身をスタンプすることを知っていますが、リモート API では、クライアントが時刻をスタンプすることを信頼します。これは意図的なものです。一方、タグのないストーリーはdefault
、どこから来たかに関係なく、タグを受け取る必要があります。オブジェクトの構築後にバリデーターオブジェクトをプラグインする自由を好むかもしれません。
コード例 (python):
def handle_remote_update(serialized_object):
#do some parsing
model_object = ModelObject(...)#fill in with parsed values
validator1.validate(model_object)
validator3.validate(model_object)
model_object.save()#All database code is in this method
#If you have to log to your system or notify listeners, that's also in this method
def handle_web_submission(post_dict):
#do some parsing
model_object = ModelObject(...)#fill in with parsed values
validator2.validate(model_object)#This wasn't executed above
validator3.validate(model_object)#This was
model_object.save()#Same code gets executed down here as above
insert
確かに、私はまたは おそらくの場合しか扱っていませんupdate
。これらの関数を呼び出す必要があるのは、メソッド スプリッターです。これは、リモート API がいつ呼び出しているかを認識し、insert
それdelete
に応じて別の関数を呼び出すものです (Web インターフェイスについても同様です)。Web フレームワークを使用している場合、これは Web インターフェース部分の urlconfig である可能性があります。