I've the following use cases:
1) a screen with a grid where you can add/edit/delete roles
2) a screen with employee information, also a combobox where you can choose the
role the employee has. The combobox has a Name Value List for displaying the
roles. There is also a button next to the combobox to add a role via an
inputbox.
For the first use case I have to create an editable root list
Roles = EditableRootList
Role = EditableChild
For the second use case I can't reuse the Role object from the first use case
because NewRole is not a public method (I'm using code smith templates)
internal static Role NewRole()
{
return new Role();
}
So I have to pass via the EditableRootList object like in the following code
private void roleLID_newSimpleButton_Click(object sender,
EventArgs e)
{
InputBoxResult inputboxRole =
InputBox.Show("Add new role :", Add role");
if (inputboxRole.ReturnCode == DialogResult.OK)
{
_roles = Roles.GetRoles();
Role _role = _roles.AddNew() ;
_role.Naam = inputboxRole.Text;
_roles.Save();
this.roleListBindingSource.DataSource = RoleList.GetRoleList();
}
}
This code I don't like because here we are getting all the roles from the
database just to add a role.
What do I have to do?
1) is role a case for a switchable object?
2) create an editable root object for Role?
3) not using the Name Value List but the Editable Root List to fill the combobox?
To explain more the idea of the second use case.
It's a little bit like in the book. You have a screen to edit/add/delete roles. When you are changing s.t. you invalidate the cache of the RoleList, so that the combobox on the screen of the project reflects the changes.
The use case that I want to implement is similar, except that I don't want another screen to edit the roles. On the same screen of project I want a button "Add role" which displays an inputbox where the user inputs the name of the new role. Also here I want to invalidate the cache of the RoleList, so that the combobox reflects the changes.
Hopefully this explains more the problem I have. What type of objects do I need to implement that?
For the combobox a ReadOnlyList and for the button "Add role" an editable root parent?
You have three use cases here.
1: Use an editable list of editable children
2: Use a NVL
3: Use an editable root (like RoleAdd or something)
As you note, use cases 1 and 3 invalidate the list used by use case 2. The book shows a caching pattern, including invalidation, that you can use to invalidate the list used by use case 2.
That technique is passive though, meaning that the NVL instance isn't notified immediately that it is invalid. If you need more immediate notification you'll need to implement an Observer pattern (pub/sub).
A simpler solution is probably to have the UI's code that handles your "Add role" button simply rebind the NVL to the UI after the add role dialog has closed. Since your editable root from use case 3 would have invalidated the NVL cache, rebinding to the NVL will force the reload. Not as "elegant" as an Observer pattern, but a LOT simpler ![Smile [:)]](/emoticons/emotion-1.gif)
This is the second solution of my proposals. Thank you for describing this solution more in detail. Especially mentioning the observer pattern. I'll investigate this. I've found some posts about that on your forum.
But should it not be easier to use the third solution I proposed : use an Editable Root List to fill the combobox.
Advantages:
1) You don't have to create a separate editable root object (like the RoleAdd you are mentioning) Normally this is not a true argument because if your use case is demanding this, so be it. But why you’re splitting my 2 use cases into three? Is this for technical reasons? Or maybe I do not understand very well the concept about use cases. I’m quite new to this area.
2) You don't have the problem with the synchronization. Also you don't have to query the database again to fill the combobox just too display this one newly added role.
Can you tell me what the disadvantages of this third solution are? I'm thinking about maybe the performance to fill the combobox let's say with 2000 roles, because we are using editable objects and not read-only objects. Is this a big difference? Do you have some numbers for the difference?
There is no technical reason why you can't use an editable list to populate a combobox.
The reason I suggested the solution I did, is because I think it is best to use single responsibility design for your objects. An object should have a single responsibility like "provide a readonly list of data" or "edit a list of data".
The result is often that you do have more classes. But also, each of those classes is simpler and more focused, which means they are easier/cheaper to maintain.
Copyright (c) Marimer LLC