Does this pattern disregard the DRY principle, and can I modify the pattern to fit?

Question

I just started working at a company and we're currently in a fairly intensive (full-days most work days) training program to bring us up to speed on the way the company does things, and train us in VB.NET, along with some C#.

They're beginning to migrate towards a modified Model-View-Presenter architecture, with server remoting playing a fairly large role. An example .NET program might look like this:

SomeSolution
|
+-+- ServerProject
| |
| +- ServerEmployee.vb
| |
| +- Server.vb
|
+-+- Presenter
| |
| +- PresenterEmployee.vb
| |
| +- Presenter.vb
| |
| +- IView.vb
|
+-+- ViewProject
  |
  +- ViewEmployee.vb
  |
  +- View.vb

The classes in question would be the employee classes. The example that I was given was that the ServerEmployee would have the most information - being retrieved from a database, it would likely have the most attributes, such as .FirstName, .LastName, .MiddleInitial, .PreferredName, .HireDate, and whatever other attributes were present on the database. The PresenterEmployee would have the other attributes, as well as a .FullName attribute that perhaps was generated this way:

If employee.PreferredName <> String.Empty Then
    employee.FullName = employee.PreferredName & " " & employee.LastName
Else
    employee.FullName = employee.FirstName & " " & Employee.MiddleInitial & " " & Employee.LastName
End If

And finally, the ViewEmployee would only have the .FullName and .HireDate attributes.

We were informed that the rationale behind this design was that if we have say, a DataStructures class that's referenced by the other classes then each time the DataStruture class has to be rebuilt, the entire project must be re-deployed (which I understand is a somewhat tedious process because of some infrastructure decisions). I understand that that would not be A Good Thing™, but it seems that if you have some code that probably won't change much (a fairly generic superclass with some straightforward properties), it would make sense to avoid the code duplication.

Am I correct in thinking that this is a violation of the DRY principle? The first thing I thought of when they taught this was "ewww, that kinda smells..."

Other than (potentially) not having to redeploy the entire application every time the superclass is changed, is there any benefit to doing things this way? And if it is broken, and I want to take the onus to try and fix it, what are some good arguments to defend my choice?

Answer 1

Once you get into the world of n-tier architecture, it becomes a question of how much separation you want between layers

A typical 3-tier architecture would be Data Layer <-> Business Layer <-> UI Layer.

The data layer would contain the database entities, the business layer would contain a view of the database entities with business logic applied and the UI layer would contain a view of the business layer with presentation logic applied.

Depending on the scope of the project, it is perfectly acceptable to re-use entities between layers if you want to avoid a lot of repetitive mapping.

It really comes down to separation of concerns versus DRY. If you need to reuse the business layer, you obviously don't want the UI layer using the business entities directly since any refactoring would have to be applied in multiple places (is having to refactor the same thing in multiple places considering a violation of DRY? :)?

The only concern I would have with the above approach is that I'm not sure how you are handling aggregated entities. My own preference is to use DDD to design the business layer so that each component is intended for a specific use case rather than just a collection of separate entities with some business logic inside them

I would recommend a tool like AutoMapper to do the mapping between layers via convention if you want the flexibility of the above approach whilst avoiding some of your DRY concerns.

Ultimately, there is no right answer tho. :(

Answer 2

Model-View-Presenter is a variation on Model-View-Controller. The whole intent is to separate display and content so that you can change one without changing the other. This also makes it easier to have the information in the model show up in multiple places in your website, and be sure that they are all in sync.

Yes, there is extra work, the structure takes some getting used to, and there is a need to synchronize stuff across files. But every so often you'll find yourself making an easy change and thinking, "Wow, that would have been a lot harder without this architecture!"

And VB-specific deployment advantages are a red herring in comparison to that.

But be warned - all of the advantages from the structure can be lost if you undermine the structure. It is very common to see teams put logic in the wrong place (for instance business logic in the view), and once that has been done it is very hard to fix that.