Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Namespace organization and naming conventions

Status
Not open for further replies.

noodle22

Programmer
May 8, 2008
23
What are typical project/namespace organization for a DB project (including accepted names...maybe people don't name things accessors)? I have been doing something like

*[project].Core.Entities - contains entity objects. Should this be called Domain or DomainObjects?

*[project].Core.Repository - contains interfaces that access the database. Currently, I name these something like I[Entity]Accessor so IStoreAccessor for saving/getting/etc store entity object(s). I'm thinking that maybe I should rename Accessor to Repository so IStoreRepository

*[project].DataAccess - contains concrete implementation of the [project].Core.Repository interfaces. It encapsulates my nhibernate code and/or ADO code. And then I have some sort of class (I guess it would be a factory) that returns instances of the I[Entity]Accessor interfaces when I need to grab data from the db

*[project].UnitTests - I'm just starting to learn about TDD so I don't know too much about this one but I guess it will contain my unit tests

lately, I have been trying out ASP.NET MVC (and I can't say enough good things about it) so my web project has the following namespaces

*[project].Controllers
*[project].Views

I really appreciate any guidance in this. I think I am on the right track now and maybe the remainder of what I am trying to figure out is subjective (ie Accessor vs Repository, Entity vs Domain)
 
Evans (Domain Driven Design) calls this ubquitous language. the names of objects, methods, (and namespaces for that matter) should reveal the intent of itself.

Since terms like DAO (Data Access Objects) and Repository are common no matter what project. I would stick with these names instead of Accessor to DatabaseGateway or something. not to mention DatabaseGateway should probally mean somethingelse entirely.

As for projects I have a minimum of 3 projects per solution
1. The core business logic
2. Unit tests
3. The GUI or service. (if I have multiple entry points [web and serivce] then they would each be a seperate project)

I haven't migrated to an MVC framework yet so I'm still bound to webforms and the asp.net pipeline. once I adopt this model I will try to reduce my soultions to 2 projects product and tests.

And then I have some sort of class (I guess it would be a factory) that returns instances of the I[Entity]Accessor interfaces
I would recommend a Dependency Injection Framework. I use Castle Windsor because Rhino Tools requires it. Another good IoC is Structure Map which is built by jeremy miller.

there are many ways to load the container but basically you give it all the individual pieces and then the IoC puts them together.
Jeremy just posted about this topic.

Jason Meckley
Programmer
Specialty Bakers, Inc.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top