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
.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
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?