-
Join the MyBroadband community
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
-
Question of the Day: What's the most interesting small town you've visited in South Africa?
A sample three-tier project [feedback required]
- Thread starter Solarion
- Start date
![[)roi(]](/forum/data/avatars/m/8/8711.jpg?1563828683){kind=avatar}
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.
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.
Last edited:
Hamster
Resident Rodent
- Joined
- Aug 22, 2006
- Messages
- 45,919
- Reaction score
- 18,416
BWHAHAHAHAHAHA!!
Solarion
Honorary Master
- Joined
- Nov 14, 2012
- Messages
- 28,051
- Reaction score
- 17,805
^
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.
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.
A good description of many OOP builds, "SOLID" they ain't
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...
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...
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/