views:

548

answers:

6
A: 

The question comes down to what you separate by namespace and what you separate by DLL. If you have a good reason to keep EVERYTHING modular, you have to work really hard. But if each of these dlls only have a class or two in them, perhaps you could merge them together?

Spence
Alex
Well the namespaces are. You use assemblies when you want to be able to update them without the whole program, and to reuse the code. But as I said if you have only one app or a small set of shared functionality then keep everything together.
Spence
A: 

Take a few minutes and sort out the procedures ... create an identifier for each project (FM, FS, FD, FU). List each publicly accessible procedure on a page and then add an identifier for a project, if that project uses the procedure ...

Then you can see which procedure needs to be in (or accessible to) which project.

Hope that helps!

Robert French
As I wrote above, the problem is that often times 2 projects need to be aware of each other. How would your approach resolve it?
Alex
If you try the suggestion you will see (among other thing i'm sure) that some of your procedures are not in the best suited projects ... for example having localization in main and not util doesn't seem right. Depending on the level of modularization your after, you may find that language management is best suited on its own entirely.
Robert French
+1  A: 

Use interfaces for all non-trivial classes. Place interfaces in a different assembly from implementation.

ima
This is what I was going to suggest for item 2. If ever you feel like two sibling assemblies need to know about classes in each other just split out an interface and have them both use that.
Spencer Ruport
A: 
  1. You can put your localized email strings in Flip.Services. The downside is that you have two places to maintain localized resources. You can also have a separate dll for all your resources to minimize the place to edit resources.
  2. You have to move the fluent interface to an other dll or make CustomerSearchFilter part of the domain.
  3. You will need to add more projects or rearrange your structure and use namespaces to create the separation.
Hakan Forss
Would making CustomerSearchFilter (and other business objects that don't have a data representation) part of the domain be considered a normal thing to do?
Alex
A: 

It sounds like your building on concrete implementations instead of interfaces/contracts. As Ima suggests define interfaces that describe what a certain class should be able to do. Use this interface when you declare properties, parameters and the like. Keep the interfaces separate from the implementaion and both the implementation and the projects that uses the interface can reference the interface project.

You then get the nice option of using dependency injection making your code easier to test as an a side

Rune FS
Do you have an example article or similar for such project structure? Is this common?
Alex
A: 

In the "tiers" of a domain, repositories and services live at the same logical level, above the domain in an infrastructure role. I would suggest moving your repository implementations (queries, etc.) outside of the domain itself. That solves #2 at least.

Bryan Watts
What kind of project would that be then? (technical term?)
Alex