Dont Repeat Yourself: Pragmatic Approaches
Jeremy Miller has posted about the DRY principal, as well as the Wormhole anti pattern. One of the pain points that was brought up was adding a field to the screen. We are currently extremely fluid with regard to the entity design, this means that new fields keep popping up and old fields are going away. I am also extremely fond of ReSharper, and I loath tables like "Cutsomers". The spelling mistake is intentional here, but I have seen systems that have this in productions. This make it fun to work with the system.
The process we use is to have a single authoritive source for our model. That model is the entities. Our entities are Active Record classes (but they do not inherit from ActiveRecordBase), so I get to specify what they do inside the code. Part of the build process would generate the database from our entities.
Assume that we are working with comments, and we have a new requirement, to show the commenter's IP. What we would need to do is:
- Add the IP Property to Comment (then run the build):
[Property(NotNull = true)]
public virtual string Ip { get { ... } set { ... } } - When we create the comment, add the IP Address of the current user.
- When we display the comment, show the IP Address as well.
In practice, we often add several fields at the same time, but it is the same principal. The only pain point in this process is the data, we have test data that needs to be modified when we re-generate the database, which can be a pain to deal with. I am searching for an answer in this matter, by the way.
Another thing that I had some experiance with is moving stuff from configuration to code. There should be only one truth, but the instict to put it in XML is the wrong approach, IMO. There are not tools to refactor XML, while code is extremely flexible under the right hands. I had success in pharsing code and generating additional code from it. In that case, it was to generate perfomance counters create/use code, from an abstract class that contain just their definitions.
At any rate, what I am trying to say is that you should aspire to a single truth as well, and you should carefully consider what kind of a truth it is. <Truth/> is not an easy apparoch.
Comments
The problem I see with this approach is that you end up with a public property which means that embedding the newly added field has at least one more location which has to be modified - either the UI or business logic external to the entity class.
Public properties are generally considered evil (see another article by Allen Holub: www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html) and usually end up causing duplicated code.
Comment preview