Code Organization Connundrum: Web Project With Multiple Supporting DLLs?

Question

Hi.

I am trying to get a handle on the best practice for code organization within my project. I have looked around on the internet for good examples and, so far, I have seen examples of a web project with one or multiple supporting class libraries that it references or a web project with sub-folders that follow its namespace conventions.

Assuming there is no right answer, this is what I currently have for code organization:

MyProjectWeb

This is my web site. I am referencing my class libraries here.

MyProject.DLL

As the base namespace, I am using this DLL for files that need to be generally consumable. For example, my class "Enums" that has all the enumerations in my project lives there. As does class MyProjectException for all exception handling.

MyProject.IO.DLL

This is a grouping of maybe 20 files that handle file upload and download (so far).

MyProject.Utilities.DLL

ALl my common classes and methods bunched up together in one generally consumable DLL. Each class follows a "XHelper" convention such as "SqlHelper, AuthHelper, SerializationHelper, and so on...

MyProject.Web.DLL

I am using this DLL as the main client interface. Right now, the majority of class files here are:

1) properties (such as School, Location, Account, Posts) 2) authorization stuff ( such as custom membership, custom role, & custom profile providers)

My question is simply - does this seem logical?

Also, how do I avoid having to cross reference DLLs from one project library to the next? For example, MyProject.Web.DLL uses code from MyProject.Utilities.DLL and MyProject.Utilities.DLL uses code from MyProject.DLL. Is this solved by clicking on properties and selecting "Dependencies"? I tried that but still don't seem to be accessing the namespaces of the assembly I have selected. Do I have to reference every assembly I need for each class library?

Responses appreciated and thanks for your patience.

Answer 1

It is logical in that it proceeds logically from your assumptions. The fact that you are asking the question leads me to believe you might not think it is rational.

In general, things should be broken down along conceptual boundaries rather than technical ones. MyProject.IO.DLL is an example of this principle surfacing in your current design. All of the IO things logically go together, so they end up in a single binary. Makes sense.

Breaking things down into namespaces based on their technical type - enum, class, etc. - is going to be a little more problematic.

The dependencies problem is the same one you'd have breaking one class up with many and it is resolved using the same technique: inversion of dependency. Where two things seemingly need to depend on one another, add an intermediary thing that represents the contract between the first two. This can be abstractions, constants, mediators etc... whatever you need to make it so that instead of thing A depending on thing B and thing B depending on thing A, you have things A and B depending on thing C.