Code Reuse

[Bob Weiner]

Hi,

I am an IT person who uses .Net to support our infrastructure. Since I have
been doing this for a while it would be a misnomer for classify myself as a
newbie; perpetual amatuer seems more appropriate.

Notwithstanding, I am tired of cutting and pasting code and moving classes
from one project to the next and would like to know the "proper" way to
store code for reuse. I have used .dll's with some success but am still not
organized.

Ideally, I'd like to have a hierarchial namespace with "myOrg" at the root.
Underneath I should find myOrg.AD, myOrg.AD.Queries, myOrg.Exchange... I
assume professional developers do it this way.

I have seen a lot on Namespaces but I haven't been able to conceptually move
from the simple concept of scope to that of organizing code for reuse.
Does this happen by creating a 1 dll / namespace, copying that dll into a
matching directory structure, then adding a reference to each dll in all
subsequent projects?

advice or referrals would be greatly appreciated.

Thanks, bob

 

[Guest]

The best way to dea with namespaces in this case is not to think of them as
part of scoping. Think of them as just a way to organize your libraries by
grouping similar things together.

You seem to be on the right track in your last paragraph except that there's
really no reason to store individual .dlls in their own directory structure.
Just make sure that the name of the .dll synchs up with the name of the
namespace. (Your source code, of course, is a different matter)

The other thing I would suggest is to plan at least your namespace
hierarchy if not the entire libraries in advance. This will help to ensure
that things get put in the proper namespace as you create them.

Good luck.

 

[Bob Weiner]

That's good to know.

Since you mentioned it, I don't know why I thought there should be a
relationship between the dll files and the namespaces. I think that might
have been an old Java concept creeping in.

Thanks!
bob

 

[sloan]

You can override the names of the files to alternate versions... if youd
like

Most people don't.

MyOrg.Applications.NorthwindManager
MyOrg.Applications.NorthwindManager.Presentation.Winforms.1
MyOrg.Applications.NorthwindManager.BusinessLogic
MyOrg.Applications.NorthwindManager.Data
MyOrg.Applications.NorthwindManager.Data.DataSets

that's am example of what I do for an application.

I put those in file/folders like this:

c:\development\MyOrg\
c:\development\MyOrg\Applications\
c:\development\MyOrg\Applications\NorthwindManager
cc:\development\MyOrg\Applications\NorthwindManager.Presentation.Winform.1
c:\development\MyOrg\Applications\NorthwindManager\BusinessLogic\
c:\development\MyOrg\Applications\NorthwindManager\Data\
(etc)

so I'd have (one example only this time)
c:\development\MyOrg\Applications\NorthwindManager\BusinessLogic\MyOrg.Appli
cations.NorthwindManager.BusinessLogic.csproj

something like that.
then I'd get a file like this:
MyOrg.Applications.NorthwindManager.BusinessLogic.dll

perhaps I override the name.... and do this:
MyOrg.Applications.NWM.BusinessLogic.dll

the NAMESPACE would remain:
MyOrg.Applications.NorthwindManager.BusinessLogic
but the filename would be
MyOrg.Applications.NWM.BusinessLogic.dll

the only time i do this is when I might encounter the overall windows issue
of filepath/names length. I think the max is .. 255 characters or something
like that??




my framework stuff would be:

MyOrg.Email
MyOrg.Data

etc

 

[jeremiah johnson]

With C#, I put all the code that I've written (and plan to reuse
elsewhere) in a lib/ folder not too far from the root of the drive. For
me, this is E:\lib\.

It takes a bit of time to learn how to separate presentation from
processing, but once you get it, you'll be cranking out APIs faster than
you can use them.