4 Replies - 431 Views - Last Post: 04 March 2013 - 09:15 AM Rate Topic: -----

#1 adn258  Icon User is offline

  • D.I.C Addict

Reputation: 11
  • View blog
  • Posts: 761
  • Joined: 31-August 11

Do You Use Multiple Namespaces And Should You?

Posted 04 March 2013 - 12:25 AM

I use a lot of different interfaces classes objects etc. But thus far for whatever reason I've never found a need to use more than one namspace. Perhaps that would better organize code? Should you use more than one? What do you do?
Is This A Good Question/Topic? 0
  • +

Replies To: Do You Use Multiple Namespaces And Should You?

#2 MrShoes  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 312
  • View blog
  • Posts: 488
  • Joined: 13-June 12

Re: Do You Use Multiple Namespaces And Should You?

Posted 04 March 2013 - 01:30 AM

Yes, you probably should do once your program increases in complexity. If you have a lot of business logic classes and a lot of data access classes, do you want access to them all together with one using statement?

Often, I even use separate projects to organize code that performs different functions. But then, that's often so I can resuse the compiled dlls in different applications or GUIs.
Was This Post Helpful? 0
  • +
  • -

#3 Momerath  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1010
  • View blog
  • Posts: 2,444
  • Joined: 04-October 09

Re: Do You Use Multiple Namespaces And Should You?

Posted 04 March 2013 - 02:21 AM

My current project has these namespaces:

Momerath
Momerath.Collections
Momerath.Collections.Generic
Momerath.Extensions
Momerath.Numerics
Momerath.Sort
Momerath.Strings
Momerath.Strings.Search

So yes, I use different namespaces to organize the classes into their various purposes.
Was This Post Helpful? 1
  • +
  • -

#4 baavgai  Icon User is online

  • Dreaming Coder
  • member icon

Reputation: 5801
  • View blog
  • Posts: 12,638
  • Joined: 16-October 07

Re: Do You Use Multiple Namespaces And Should You?

Posted 04 March 2013 - 04:55 AM

Namespaces are a little like objects; you can go nuts. Don't go nuts.

Each assembly might have it's own namespace, but then it mightn't. I have things like:
DIC.Common
DIC.Common.UI // sometimes you need Winforms, often not

// an actual application
DIC.TicTacToe // only need one, this is the name of a application assembly

// a more complex application
DIC.Stocks.Lib // This will be the controller layer
DIC.Stocks.Model // obvious, however, this might simply reside in Lib

DIC.Stocks.Service // Will expose DIC.Stocks.Lib via web service, so it's essentially an application
DIC.Stocks.Web // This is an actual application, driven by either DIC.Stocks.Lib or DIC.Stocks.Service
DIC.Stocks.App // Winforms application, driven by either DIC.Stocks.Lib or DIC.Stocks.Service



Don't mistake Namespaces for internal organization. In Lib I'll usually have a Model or Contract folder and almost certainly a Database folder. I will possibly have an interface folder, depending on how unruly they're getting. None of these will be a separate namespace.
Was This Post Helpful? 2
  • +
  • -

#5 ThrowsException  Icon User is offline

  • D.I.C Head

Reputation: 33
  • View blog
  • Posts: 83
  • Joined: 21-February 12

Re: Do You Use Multiple Namespaces And Should You?

Posted 04 March 2013 - 09:15 AM

To add to MrShoes answer namespaces are a great way to add functionality or features later without changing existing code. You'll see Microsoft do this a lot where you'll try to use a feature but have to import two dll's that contain the same namespace.

I've found it an effective way to define base functionality in one project using a namespace but then later on in the project a team may create extensions or add new features to an existing namespace to extend features that are already working. New development gets to continue using updated features without having to modify code that is already working but you have the ability to go back and refactor it using the new features without importing any new namespaces. just add the compiled dll you need.

It's about keeping your codebase terse for builds. You'll find in large projects bringing in a lot of very large namespaces will begin to slow your compiles down. Having them in neat cohesive packages lets you target only the features you want in your code and leave out what you don't.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1