views:

129

answers:

2

Can anyone summarize or bulleted list the types of things that go in each layer, and what layers are there in an MVC type design if you account for Dependency Injection?

I haven't found any clean diagrams that help me figure out where or try to go more in detail without writing an entire book.

I've been doing windows forms apps (including the sql server database design) for 3 years now as my sole function at work , with no one more experienced over me. I have been trying to break things apart into clean layers as much as I can figure my way through on my own based on presentation, business, database.

However based on reading the samples of Dependency Injection in .net it appears that the business logic should be the heart of the application with a separate layer that points to the specific database implementation. So then the ui goes in the presentation layer, controller just provides an abstraction/mapping layer to what the ui is allowed to do in the model layer, the business logic goes in the model layer, and the database/linq-to-sql goes in the database layer. Where everything can depend on the model layer, but it should depend on nothing.

To enable you to move the heart from X type to:

  • Windows forms
  • Asp.net
  • Asp.net MVC
  • Silverlight
  • Anything else

right? Would a 4 layer/project approach cover this type of thing? I suppose it would be 5 if you add a TDD layer.

I'm not averse to reading books, but I have plenty to read ( 3 at home, 1 at work, 3 ordered, 1 for college) already that are quite thick. Both of these approaches have resounding supporters but seem to conflict on overall design.

A: 

I think this link will cover most of your questions: http://wiki.sharparchitecture.net/SettingUpNorthwind.ashx

It's not possible to compare MVC vs dependency injection.

Dependency injection is often used in MVC to make the controller and the view independent of how the data is persisted.

orjan
@orjan - can you summarize any of the ways in which it answers? I'm trying to sort through the article, but I don't have any experience with NHibernate, WCF, or asp.net MVC. Also it defers discussion of what a coordination layer is to 3 other books instead of going into detail.
Maslow
@orjan - I don't think I'm comparing the two as the question title may suggest, I'm trying to envision how they would pair up when used together in any application architecture.
Maslow
+1  A: 

I think you're trying to understand too much at one time. For instance, a "TDD layer" makes no sense. DI and MVC are only tangentially related. DI does not specify what layer the business logic should be in.

Start simple. Work on one concept at a time. Test out your knowledge in one language before trying to apply it everywhere. You've got some great books on your reading list; work through some of them. The Art of Unit Testing will give you a basic understanding of TDD; it covers pragmatic uses of Dependency Injection as well, but doesn't go very deeply into it. The Extreme Programming series will cover TDD in more detail.

I'd suggest reading up on design patterns (don't start with the Gang of Four book - maybe Head First Design Patterns) and general design principles (Clean Code is a good start). Perhaps others can suggest references for learning about layered architecture.

Expect this to take a while. Expect to continue learning throughout your career.

TrueWill
Specifically, the dependency injection book says that the business logic should have no other depenedencies, so you can move it around into other forms of that same 'application'. Which makes sense, but the model in an MVC appears to want to have your business logic in the same layer with persistence/database. is this correct or would a 4 layer/assembly layout work better?
Maslow
@Maslow: The business logic does go in the model, but the model itself can (and generally should) be layered.
TrueWill
...and to extend my previous comment - the view and controller see only the public interface of the model. The inner workings (persistence layer, supporting classes, etc.) are hidden from them.
TrueWill
+1 so then there would be a model, view, and controller, but, the model may be multiple assemblies (or layers depending on how you look at it).
Maslow
@Maslow: Absolutely. Multiple layers can be in a single assembly, though.
TrueWill
I would think the database/persistance layer being in the same assembly with the business model would defeat the purpose of dependency injection in the sense that swapping out to a different storage medium (windows azure for instance) would be much more work than just removing the reference and adding a reference to the newly written one.
Maslow
@Maslow: It depends. If you're using an O/RM (which would be in a different assembly) you would just change the configuration. If you're using DI solely for testability, you may never swap storage in production code. My point is that layer != assembly.
TrueWill