DAO 在项目结构中应该放在哪里？
我正在 VB.Net 中开发一个项目，需要实现 DAL。我不太确定项目中的哪个位置是放置 DAO 的最佳位置。我应该将 DAO 与将要使用它们的业务对象放在同一名称空间中吗？或者我应该将所有 DAO 放在一起。
我有 Java 背景，这可能会影响我对您的 .Netish 答案的理解。 :)
I am working on a project in VB.Net and need to implement the DAL. I am not quite sure where in my project is the best place to stick the DAOs. Should I stick the DAO in the same namespace as the business objects that are going to use them. Or should I lump all the DAOs together.
I have a Java background which might taint my understanding of your .Netish answer. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我总是努力保持一切美好整洁。
即使它是一个小项目，您也应该尝试并维护某种模块化设计。我的手指经常被烫伤。
例子：
PG.CustomerCare.DAL <-- 数据访问层
PG.CustomerCare.BO <-- 业务对象 <-- 这可能会取代服务。
PG.CustomerCare.Services <-- 对业务逻辑进行抽象的服务，这个会有对 DAL 的引用
PG.CustomerCare.Client.Web <-- 只与服务层交互
PG.CustomerCare.Client.Winforms < -- 这里同样，只与服务层交互。
I always try to keep things nice and tidy.
You should try and maintain some kind of modular design even if it's a small project. I've burnt my fingers way too often.
Example:
PG.CustomerCare.DAL <-- Data Access Layer
PG.CustomerCare.BO <-- Business Objects <-- this might replace the Services.
PG.CustomerCare.Services <-- Services to abstract the business logic, this will have a reference to the DAL
PG.CustomerCare.Client.Web <-- Only interacts with the service layer
PG.CustomerCare.Client.Winforms <-- Same here, only interacts with the service layer.
当谈到这个级别的项目结构和设计（大型编程）时，.NET 和 Java 之间没有太大差异。
创建 DAO 时，我倾向于将它们作为实体保存在自己的命名空间/程序集/项目中。如果它们只是没有逻辑的 DTO，情况尤其如此。
When it comes to project structure and design at this level (programming in the large), there are not many differences between .NET and Java.
When creating my DAO, I tend to keep them in their own namespace/assembly/project as Entities. This is particularly the case if they are simply DTOs that have no logic in them.
我认为这取决于你的设计规模。如果我采用模块化设计方法，我倾向于将 DAO 与相应的业务逻辑放在同一个程序集中。
例如，如果我有一个管理字母持久性的 letterDAO，那么我倾向于将其与字母业务逻辑和字母实体放在同一个程序集中，并位于诸如 [company].[project].Letters 之类的命名空间下。这样所有字母功能都集中在一处，我可以更轻松地配置或替换它。
如果我有一个 applicationDAO，那么它是相同的，但在 [company].[project].Applications 等下。
I think it depends on the scale of your design. If I have a modular design approach I tend to put DAO's in the same assembly as the corresponding business logic.
For example, if I have a letterDAO which manages the persistence of letters then I tend put that in the same assembly as the letter business logic and the letter entities under a namespace such as [company].[project].Letters . So that all the letter functionality is in one place and I can configure or replace it easier.
If I have a applicationDAO then its the same but under [company].[project].Applications etc.