“Engineers are retarded. They are half some kind of brain damaged that allows them not to have social skills so that they can concentrate long enough to write code. But this is a disease… That’s why I had to quit… It just makes you retarding…”- Jim Reekes
Inside the Sausage Factory: PART 01 (Preamble)
Inside the Sausage Factory: PART 02 (Buy vs. Build?)
Inside the Sausage Factory: PART 03 (_DD)
Inside the Sausage Factory: PART 04 (Feature Driven Development)
Inside the Sausage Factory: PART 05 (Ranking Features)
Inside the Sausage Factory: PART 06 (Data by Design)
Inside the Sausage Factory: PART 07 (Refining the Data Model)
Inside the Sausage Factory: PART 08 (Scripting the Database)
Inside the Sausage Factory: PART 09 (Layers and Foundations)
Inside the Sausage Factory: PART 10 (Choosing The Vietnam of Computer Science…on purpose!)
Inside the Sausage Factory: PART 11 (Dynamic Data Transfer Layer)
Inside the Sausage Factory: PART 12 (UI Mockup)
Inside the Sausage Factory: PART 13 (Data Access Design)
Inside the Sausage Factory: PART 14 (One-liners: the power of libraries)
Inside the Sausage Factory: PART 15 (Strategies for dynamic, ad-hoc run-time queries)
Inside the Sausage Factory: PART 16 (burn-down rates — reality-check!)
Inside the Sausage Factory: PART 17 (Approach to testing the DAL)
Inside the Sausage Factory: PART 18 (Building Data-dependent Unit Tests)
Inside the Sausage Factory: PART 19 (Coding the Data-dependent Unit Tests)
Inside the Sausage Factory: PART 20 (Detour to fix NDbUnit Foreign Keys)
Inside the Sausage Factory: PART 21 (On Model-View-Presenter Patterns)
Inside the Sausage Factory: PART 22 (Mocking the View)
Inside the Sausage Factory: PART 23 (Detour…derailed by CIFactory)
Inside the Sausage Factory: PART 24 (NAnt MbUnit task filter detour)
Inside the Sausage Factory: PART 25 (Arrested by an FxCop)
Inside the Sausage Factory: PART 26 (Building The Dumb View)
1. Layer: Messenger
2. Layer: Broker
3. Layer Dispatcher
In context of exploring the Model View Controller (MVP) pattern I came across following collection of links.
It also contained a link on Four Layer Architecture:
Problem:
When designing an object system for a client-server environment, what is the most appropriate way to structure the overall application architecture? How do you structure your system when you have both significant presentation and domain components?
…
The View layer. This is the layer where the physical window and widget objects live. It may also contain Controller classes as in classical MVC. Any new user interface widgets developed for this application are put in this layer. In most cases today this layer is completely generated by a window-builder tool.
The ApplicationModel layer. This layer mediates between the various user interface components on a GUI screen and translates the messages that they understand into messages understood by the objects in the domain model. It is responsible for the flow of the application and controls navigation from window to window. This layer is often partially generated by a window-builder and partially coded by the developer.
The DomainModel layer. This is the layer where most objects found in an OO analysis and design will reside. Examples of the types of objects found in this layer may be Orders, Employees, Sensors, or whatever is appropriate to the problem domain.
The Infrastructure layer. This is where the objects that represent connections to entities outside the application (specifically those outside the object world) reside. Examples of objects in this layer would include SQLTables, 3270Terminals, SerialPorts, SQLBrokers and the like.
Articels by Martion Fowler:
Articels on Nikola Malovic’s blog:
Overview: