How much autonomy do you give developers in applying patterns?

Question

I get to work with a number of companies, mostly with architects/lead developers and sometimes directly with the developers. One thing that comes up often is that when architects prescribe an application pattern, they want it to be followed consistently every time with little to no room for variation.

Presentation Model/M-V-VM

A good example of this is the Presentation Model (M-V-VM) pattern. When I think of this pattern, I think of it as "we have an object model to represent the state and behaviors of the current scenario, and a view object that surfaces it to the UI". In my mind, the things representing the state (the model/view model) is more conceptual than a prescriptive guide. A view might use many objects to represent this state, or it might use one, or perhaps it is so simple that it needs none, or perhaps it shares one. The ethos of the pattern is that we seperate the state management from the visualization code.

However, often what I come across is the patterns being intepreted much more literally. A typical project might look like this:

• Views
  • Foo
    • FooView.xaml
    • FooView.xaml.cs
    • FooViewModel.cs
    • FooModel.cs
  • Bar
    • BarView.xaml
    • BarView.xaml.cs
    • BarViewModel.cs
    • BarModel.cs

Sometimes, the Model object is empty, or the ViewModel is just forwarding property getters/setters to the model object. Sometimes the view is so simple, that the extra objects just make it more complicated than it needs to be.

As architects/team leads, do you prefer developers follow the same process every time like a checklist? Or do you prefer to leave the details up to the developers?

Answer 1

Leave the details up to the developers, every time. Some solutions may get wild & hairy, but trying to control the details is a losing game for all. Developers have brains: tell them what you want them to achieve before telling them exactly how. When defining a reference architecture to be followed, focus on

• Providing basic principles to follow: what's to be done, why, and the most important consequences.
• Ensuring there are standards to be followed for e.g. coding and component usage
• Providing patterns that support the principles. You're using Presentation Model for a reason, in order to achieve a specific set of nonfunctional requirements and business objectives. Tell them those reasons, and tell them in what ways you are going to get there.
• Ensuring there are well-defined practices for things like version control and testing

Your job as architect is to ensure that the major nonfunctional requirements are identified, prioritized and achieved. Most of the time, at least in those company cultures I've worked with, acting as a guide and teacher is far more productive than trying to do all the thinking for others.

Answer 2

While Pontus makes good points; the problem is that the Presentation is actually the structure of the application. So there isn't really a choice if you want to add new functionality.

My own CAD/CAM application is quite rigid in this regard. Functionality is added through creating new Command object that manipulate the model. You need to use the objects developed by using the memento pattern to save the initial state and then save the changed state so that undo/redo is properly implemented.

Then you have to put the Command object in one of the event handling structures in the View that was developed using Passive View. Of course the choice of algorithms, supporting object and functions WITHIN the command object our developers have a fair amount of discretion.

If you are talking about NEW applications that are made by a company then there is often a good reason while the various patterns are chosen. IN our company we have to maintain our application over decades so design adaptability is very important. We can't use the flavor of the month in development as it will come back and haunt us 5, 10, 15 years later. So many of our application are designed using Passive View and multiple layers connecting through well defined interface. This served as well when MS decided to axe VB6 in favor of VB.NET

Then sometimes is just the manager following the flavor of the month. In this case you need to try to educate the manager as to why your proposed method will work out better for the company in the long run. Otherwise then you need educate yourself as to why the company chose the standards it did.