0

I need help here to find the right approach. Let us assume we have a list of N items (objects) which have a value for a property loaded from a data source. This value can be changed through the object and has to be written back to data source at a point. Currently I have two different approaches to track changes and to take care of them. Please see simple sample code below.

Approach #1: A routine to check if any object data has been changed. If so, changes will be written to data storage. This routine can be called by user command, cyclic by a timer or at the point of program closure.

Public Class FooItem
  Private intItemID As Integer    ' Will help to identify the item.
  Private intValue As Integer     ' Value for this item.
  Private bModified As Boolean    ' Identifies if value has been changed.

  Public Property Value As Integer
    Get
      Return intValue
    End Get
    Set (values as Integer)
      intValue = value
      bModified = True
    End Set
  End Property

  Public Property Modified As Boolean
   ' Return bModified and reset it if requested.
  End Property
End Class

' Somewhere in code, N instances of FooItem will be created.
' Data is loaded to the VALUE property of each FooItem object.
For i as Integer = 1 to N
  Dim objNewItem As FooItem
  objNewItem.Value = LoadData(i)
  tblFooItems.Add(objNewItem)
  objNewItem = Nothing
Next i

' Check for an item which has been changed. It can be done either
' cyclic with a timer or upon a user command or at least at the end ...
For Each objFoo in tblFooItems
  If objFoo.Modified Then
    ' Do the job to write changes to data source.
    WriteData(objFoo)
    ' Once job is done, the Modified property will be set to false.
    objFoo.Modified = False
  End If
Next

Approach #2: Raising an update event and trigger routine to write data to storage. Will immediately write changes to data storage and so no user interaction nor cyclic timer to track changes is necessary.

Public Class FooItem
  Private intItemID As Integer    ' Will help to identify the item.
  Private intValue As Integer     ' Value for this item.
  ' Event definition for update of value:
  Public Event Update (ByVal sender As Object, ByVal e As EventArgs)

  Public Property Value As Integer
    Get
      Return intValue
    End Get
    Set (values as Integer)
      intValue = value
      RaiseEvent Update(Me, New EventArgs())
    End Set
  End Property
End Class

' Somewhere in code, N instances of FooItem will be created.
' Data is loaded to the VALUE property of each FooItem object.
For i as Integer = 1 to N
  Dim objNewItem As FooItem
  objNewItem.Value = LoadData(i)
  tblFooItems.Add(objNewItem)
  AddHandler objNewItem.Update, AddressOf FooItemUpdate
  objNewItem = Nothing
Next i

' One item will be changed, event is raised and will start
' the routine to save the value of this object to disk.
Public Sub FooItemUpdate (ByVal sender As Object, ByVal e As EventArgs)
  WriteData(sender)
End Sub

In addition, I could think of a third option: The class FooItem would get "Load" and "Save" methods implemented, so the object itself has the responsibility of to load and save the data. But this idea seems to be a wrong path because it would oversize the object FooItem. It has to know where to get the data or which data storage and finally the error handling.

Public Class FooItem
  Public Sub New(ByVal sDataFile As String)
    ' [...]
  End Sub

  Private Function LoadValue() As Boolean
    ' [...]
  End Function

  Private Function SaveValue() As Boolean
    ' [...]
  End Function
End Class
  • What is your question? – D Drmmr Jan 1 at 19:58
  • My question is: What is the best approach? Are those both approaches good or bad? I cannot determine, I feel blocked because both are good and bad at the same time. Perhaps I miss another solution. – Toby N. Jan 1 at 20:07
  • "This value [...] has to be written back to data source at a point." - but which point in time / how does the application trigger this? In UI applications, there is often a certain set of work items associated with the visible screens or windows, and the user triggers the saving explicitly, for example, by pressing a "Save" button. For this kind of applications, you often don't need to track at the object level if something has changed, the "screen" or level would be sufficient. – Doc Brown Jan 1 at 21:47
  • 1
    ... or in other words: we cannot tell you the "right" approach, because it heavily depends on the UI design / maybe on the business requirements. So first you need to know what the requirements for saving are in your specific application, then start thinking about a solution. Don't try it the other way round, that does not work. – Doc Brown Jan 1 at 21:50
0

Approach 2 is more flexible, because it decouples how/when changes are stored from the item representation. You can have an event handler that stores the changes directly and another one that merely stores which items have been changed, such that you can write all changes when some function is called (i.e. same design as in approach 1). You can also switch between both methods at runtime. Or you can add an event handler that offloads writing changes to another thread. All without touching the item representation.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.