A sample three-tier project [feedback required]

[[)roi(]]

http://martinfowler.com/books/eaa.html

 

[Hamster]

/waits for SOLID

 

[_kabal_]

the more tiers the better. noone wants code that is easy to follow and read.

every tier must also implement MVC. API via classes/objects is so 2010.

also make sure that every tier transforms it's domain object into DTO's which are basically identical to the original domain object.

 

[Hamster]

the more tiers the better. noone wants code that is easy to follow and read.

every tier must also implement MVC. API via classes/objects is so 2010.

also make sure that every tier transforms it's domain object into DTO's which are basically identical to the original domain object.

BWHAHAHAHAHAHA!!

 

[Solarion]

^
Ja no sometimes it gets a bit ridiculous. A 3-tier, entity framework, MVC layered to hell and back for a few forms. I've seen a couple of those.

The coder just did it to get paid more, took a small 1 day job and spread it over weeks.

 

[[)roi(]]

the more tiers the better. noone wants code that is easy to follow and read.

every tier must also implement MVC. API via classes/objects is so 2010.

also make sure that every tier transforms it's domain object into DTO's which are basically identical to the original domain object.

A good description of many OOP builds, "SOLID" they ain't

 

[Spacerat]

Read up on onion architecture, which IMHO is one of the best on the table. You have to distinguish between layers and tiers. They are different. For all apps I like to use the following layers:



UI | Business | Persistence

For WinForms, UI is split into Presentation | Behaviour where Presentation is just the form and controls (View). No code in the form, just binding to the Behaviour Layer. The Behaviour is actually a ViewModel, so the UI follows MVVM pattern. All UI behaviour (UX) is driven by the VM. The VM is agnostic wrt what View is bound to it to the extent that it does not even use the System.Windows.Forms assembly. Here you get true separation of concerns. The View (form) is only presentation. The VM is only behaviour.

The Business layer is split into Services Layer and Domain Layer.
The Services Layer purely provides the outward facing APIs exposed as interfaces. The ViewModel only talks to the Services Layer. This means that you can slot in any transport between VM and Services Layer. For MVC apps, the controller also only talks to Services Layer. So you can hook any client technology to the Services Layer (web/winforms/mobile, etc).

The Domain Layer is where all the domain knowledge and intelligence lies.

The Persistence Layer is a very thin layer taking care of the DB stuff.

The great thing about these layers is that each layer has a definite role. Also great for automated testing. Your tests simply invoke the Services Layer methods to test all possible scenarios. To test the UI, your tests simply hook onto the VM as a View. The VM is none the wiser.

One of the best blogs I have ever read is from Mark Seeman, especially is older stuff. Mind expanding stuff...

 

[Solarion]

Thanks for the explanation Spacerat. I've actually screenshotted your post for future reference. I'm busy working through a tutorial in building a 3-tier VB.NET app.

 

[Spacerat]

Thanks for the explanation Spacerat. I've actually screenshotted your post for future reference. I'm busy working through a tutorial in building a 3-tier VB.NET app.

Cool, here is the original Onion Architecture article.
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
Quite a few nay-sayers as usual, but take from the article what is appropriate to you.

Here is Mark Seeman's blog. Read his older stuff. If you into architecture and serious about design patters etc, its a must-read. Also his book on dependency injection is an absolute must-read for all developers
http://blog.ploeh.dk/