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. :)
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.
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.
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.