Patterns

CodingYoshi

Hi, Lets say I have a class called Person with properties Name, Age, Salary. I create a GUI form to show object of this class so users can do CRUD operations on it. Each property will have a textbox for manipulation. However, if my client adds another field to Person, lets say Phone Number, then I will need to modify the database, the data access layer, the class itself, and finally add another textbox to the GUI for phone number. My question is what pattern can I use to handle a situation like above when clients constantly change properties? I am thinking of using MVC pattern but that will be for other reasons and will not help my question above.

Leslie Sanford

CodingYoshi wrote:

However, if my client adds another field to Person, lets say Phone Number, then I will need to modify the database

If your users are performing CRUD operations, do you even need a Person class? Why not perform the operations on the database itself? As far as adding fields to a table, this represents changing the database schema. That's non-trivial; I'm not familiar with a pattern that somehow hides or manages those kinds of changes. They're fundamental and will require all the work you mentioned.

Mark Churchill

The way most "modern" (and by this I don't mean code generators) data layers perform the O/R mapping between the business object definitions and the database is by a set of metadata that describes how the fields match up. So when you add a "Favourite Colour" field, you add the field to the database. Then (either manually or automatically depending on your tool) add the field to your business object, and update the mapping. The mapping is then used to handle the actual queries at runtime. A basic CRUD form could be generated at runtime using a similar set of metadata. Diamond Binding uses attributes on the business objects to say "this field comes from FaveColor" - you could use a similar strategy to decorate your business objects with "default view/controller" attributes - or chuck this mapping in a seperate file (probably a "technically" better solution than having your model aware of the default view/controller). You could end up with the class being decorated with [DefaultEditor(typeof(AutomagicCRUDController), typeof(AutomagicCRUDView)] and your new Colour field having a [FieldEditor(typeof(ColorPicker))]. Unfortunately I think you'll find that your clients will end up wanting minor changes to every form you show them, and you'll end up with something pretty close to doing it manually anyway. So my pattern tip is "Hire a load of graduates and get them used to the pain of dealing with clients" ;)

Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.

CodingYoshi

Great. Thanks for the explanation and honesty. I just thought I might be doing something wrong because a good design should not cause a ripple effect--I guess that is just "theoretically speaking".

Urs Enzler

The real problem here is that most clients think that a simple new field is something trivial to add. But it's not because: - How should it be presented in the UI (UI Layer) - Do the validation rules checking the consistency change (Logic Layer) - compatibility with old data (Logic Layer, DB Layer) - Persistency impact (behavior of database, growth, indices, replication, transfer to data warehouse) (DB Layer) And propably some more...

-^-^-^-^-^-^-^- no risk no funk

Mark Churchill

Hrmmmm, it depends on how many business rules are coming with the new data. If a simple "data-only" field is non-trivial to add then you are probably using the wrong tools. Of course, the client should have signed off on the domain model and user stories by then anyway, so for modifications at this late stage they are probably paying per-hour anyway... :P

Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.

Urs Enzler

You're right, if it is a simple data-only field, it should be simple. But in my experience, it is very seldom a data-only field (at least at the end when the customer says: "Oh, I thought it was clear that this and that business rules has to be changed because of that new field"). The result is some more iterations ;-)

-^-^-^-^-^-^-^- no risk no funk

Samer Aburabie

If its me ... I think I would solve this issue by using the concept of metadata ... the concept ! .. Well in this particular case I think I would use reflection and .NET Attributes ... reflection will help me to get the Fields (Person Class Properties) ... and .NET Attributes to determine which Fields shall be used ... for example

public class Person
{
private string name;
[Displayable]
public string Name
{
get { return name; }
set { name = value; }
}
private int age;
[Displayable]
public int Age
{
get { return age; }
set { age = value; }
}

        private string officialID;
        
        public string OfficialID
        {
            get { return officialID; }
            set { officialID = value; }
        }	
    }

Now the Displayable Attribute is a custom .NET Attribute you create ... using reflection I can determine whether this Field has the Displayable attribute or not ... and some kind of class will know how to map this class with its Displayable Fields to the UI for example ... Hard ... but doable ... and in complex applications could lead to problems if its not designed well ... but mainly in rare cases like yours it could work depending on your business.

Sincerely Samer Abu Rabie Note: Please remember to rate this post to help others whom reading it.