私はVB.Netでプロジェクトに取り組んでおり、DALを実装する必要があります。プロジェクトのどこにDAOを固定するのが最適かはよくわかりません。DAOを、それらを使用するビジネスオブジェクトと同じ名前空間に固定する必要があります。または、すべてのDAOをまとめる必要があります。
私はあなたの.Netishの答えの私の理解を損なうかもしれないJavaのバックグラウンドを持っています。:)
私はVB.Netでプロジェクトに取り組んでおり、DALを実装する必要があります。プロジェクトのどこにDAOを固定するのが最適かはよくわかりません。DAOを、それらを使用するビジネスオブジェクトと同じ名前空間に固定する必要があります。または、すべてのDAOをまとめる必要があります。
私はあなたの.Netishの答えの私の理解を損なうかもしれないJavaのバックグラウンドを持っています。:)
このレベル(大規模なプログラミング)でのプロジェクトの構造と設計に関しては、.NETとJavaの間に多くの違いはありません。
DAOを作成するとき、私はそれらをエンティティとして独自の名前空間/アセンブリ/プロジェクトに保持する傾向があります。これは、それらがロジックを持たない単なるDTOである場合に特に当てはまります。
デザインの規模にもよると思います。モジュール設計のアプローチを採用している場合、DAOを対応するビジネスロジックと同じアセンブリに配置する傾向があります。
たとえば、文字の永続性を管理するletterDAOがある場合、それを文字ビジネスロジックおよび文字エンティティと同じアセンブリに[company]。[project].Lettersなどの名前空間で配置する傾向があります。すべての文字機能が1つの場所にあり、構成や置換が簡単にできるようにします。
私がapplicationDAOを持っている場合、それは同じですが、[company]。[project].Applicationsなどの下にあります。
私はいつも物事をきれいに保つようにしています。小さなプロジェクトであっても、ある種のモジュラー設計を維持するようにしてください。私はあまりにも頻繁に指を火傷しました。
例:PG.CustomerCare.DAL<-データアクセス層
PG.CustomerCare.BO<-ビジネスオブジェクト<-これはサービスを置き換える可能性があります。
PG.CustomerCare.Services <-ビジネスロジックを抽象化するサービス。これには、DALへの参照があります。
PG.CustomerCare.Client.Web<-サービスレイヤーとのみ対話します
PG.CustomerCare.Client.Winforms <-ここでも同じですが、サービスレイヤーとのみ対話します。