Great video! I stated playing with the ideas and started a test project. One thing I seem to mis is the following. When I rebuild the CodeCampServer project and look in the UI bin folder all the dll's of the other projects are there. Even though only the core dll is referenced. How is this done? When I build my own project only the core dll is in the bin dir of the UI project...

Marc

Forget my question... The output path of the others projects is set the the UI projects bin dir.

Marc

I hope this blog post isn't too old to ask a question regarding Onion Architecture. :)

How do you handle dependencies on services from the core objects layer? Taking an overdone example, let's go with the typical order processing scenario. One requirement is that each new order have a unique, sequential, human-readable number of some kind. So I have an OrderNumber value class. To get the unique and sequential part, I'll need to somehow persist the last number used. That means that my OrderNumber.New method now has a dependency on some kind of persistence.

I thought about moving the persistence dependency into a number generation service, but then the OrderNumber.New method has a dependency on that service.

So now I figured, move the whole shebang into an OrderTracking service and have that service assign the number to the Order. This sounds semantically correct, but going down this path I'll eventually have a core objects layer containing nothing but anemic dataset-style objects with no behavior.

How would you implement something like this with the Onion architecture?

After reading MVC in Action and watching the video I think I have a much better understanding on how to handle dependencies at the architectural level. How would you structure an MVC application that has a core layer that is exposed via a Rest WCF service for third party integrations? Would you try to use the WCF services inside of the MVC application? At what point would you start exposing a "CustomerService" instead of a "CustomerRepository" to the UI layer?

Thanks for this webcast. There's something I don't quite get when it comes to dependencies. You're saying it's not enough to worry about just who references what - you also have to care about transitive dependencies. Reason: Changes to downstream modules (reference-wise) cause upstream modules to be rebuilt. The rule of thumb you say is this: Do changes in Module A cause Module B to need to be re-tested? Fair enough! I understand that, if Module B fulfills services for Module A but Module A doesn't reference B - then Module A doesn't need to be recompiled for changes to B.

But couldn't you be more lax on this and trust your interface between A and B so that, even if A references B, as long as B adheres to the interface and there are no code changes in A, A doesn't need to be retested? Then this transitive dependency doesn't matter because the strong interface firewalls it?

Or couldn't you be more firm on this and say, if B changes and the call trace goes from A to B (even if A doesn't reference B) then A needs to be retested to ensure integration? Isn't this also a form of transitive dependency?

I guess I don't get why references sufficiently predicate the issue of retesting modules and declaring dependence.