タグ付けされた質問 「business-logic-layer」

私はDjangoでプロジェクトを書いていて、コードの80％がファイルにあることがわかりましたmodels.py。このコードは混乱を招き、一定の時間が経過すると、実際に何が起こっているのか理解できなくなります。 ここに私を悩ませるものがあります： モデルレベル（データベースからのデータの処理のみを担当するはずでした）もメールを送信したり、APIを他のサービスに提供したりしているのは醜いです。 また、ビジネスロジックをビューに配置することは、制御が難しくなるため、許容できません。たとえば、私のアプリケーションでは、の新しいインスタンスを作成する方法が少なくとも3つありますがUser、技術的には均一に作成する必要があります。 モデルのメソッドとプロパティが非決定的になるとき、および副作用が発生するときはいつでも気が付きません。 これは簡単な例です。最初は、Userモデルは次のようでした。 class User(db.Models): def get_present_name(self): return self.name or 'Anonymous' def activate(self): self.status = 'activated' self.save() 時間の経過とともに、次のようになりました。 class User(db.Models): def get_present_name(self): # property became non-deterministic in terms of database # data is taken from another service by api return remote_api.request_user_name(self.uid) or 'Anonymous' def activate(self): # method …

484 python  django  model-view-controller  data-access-layer  business-logic-layer 

まず、誰かがだまされて叫ぶ前に、私はそれを簡単なタイトルに要約するのに苦労しました。別のタイトルは「ドメインモデルとMVCモデルの違いは何ですか？」だったかもしれません。または「モデルとは何ですか？」 概念的には、モデルはビューとコントローラーによって使用されるデータであると理解しています。それを超えて、モデルを構成するものについては多くの異なる意見があるようです。ドメインモデル、アプリモデル、ビューモデル、サービスモデルなどとは何ですか。 たとえば、リポジトリのパターンについて最近尋ねた質問で、リポジトリはモデルの一部であると空白で言われました。ただし、モデルを永続性モデルおよびビジネスロジック層から分離する必要があるという他の意見を読みました。結局のところ、リポジトリパターンは、具体的な永続化メソッドをモデルから切り離すことになっているのではないでしょうか。ドメインモデルとMVCモデルには違いがあると言う人もいます。 簡単な例を見てみましょう。MVCデフォルトプロジェクトに含まれているAccountController。含まれているアカウントコードの設計が不十分である、SRPに違反しているなど、いくつかの意見を読みました。MVCアプリケーションの「適切な」メンバーシップモデルを設計する場合、それは何でしょうか。 ASP.NETサービス（メンバーシッププロバイダー、ロールプロバイダーなど）をモデルからどのように分離しますか？それともあなたはまったく？ 私の見方では、モデルはおそらく検証ロジックを備えた「純粋」である必要がありますが、ビジネスルール（検証以外）から分離する必要があります。たとえば、新しいアカウントが作成されたときに誰かにメールを送信する必要があるというビジネスルールがあるとします。それは私の見解では実際にはモデルに属していません。それで、それはどこに属しますか？ この問題に光を当てる気がある人はいますか？

86 asp.net-mvc  model-view-controller  design-patterns  business-logic-layer