Implementing IDisposable in VB.NET

Encoder PDF417 in VB.NET Implementing IDisposable

In such cases, the business object should implement the IDisposable interface, which will allow the UI code to tell the business object to release its resources. This interface requires that the object implement a Dispose() method to actually release those resources: <Serializable()> _ Public Class MyBusinessClass Inherits BusinessBase(Of MyBusinessClass) Implements IDisposable Private mDisposedValue As Boolean Protected Sub Dispose(ByVal disposing As Boolean) If Not mDisposedValue Then If disposing Then ' free unmanaged resources End If End If ' free shared unmanaged resources mDisposedValue = True End Sub Public Sub Dispose() Implements IDisposable.Dispose Dispose(True) GC.SuppressFinalize(Me) End Sub Protected Overrides Sub Finalize() Dispose(False) End Sub End Class The UI code can now call the object s Dispose() method (or employ a Using statement) when it has finished using the object, at which point the object will release its expensive resources. Note, however, that if a business object is retrieved using a remote data portal configuration, the business object would be created and loaded on the server. It s then returned to the client as discussed in 4. The result, however, is that there s a copy left in memory on the server. Because of this, there s no way to call the business object s Dispose() method on the server. To avoid this scenario, any time that the data portal may be configured to run outside of the client process, the business object designs must avoid any requirement for a Dispose() method. Happily, this is almost never an issue with a properly designed business object, since all database connections or open files should be closed in the same method from which they were opened.

If you re calling a remote data portal, you must avoid object designs that require IDisposable. Alternatively, you can modify the SimpleDataPortal class to explicitly call Dispose() on your business objects on the server.

As you ve seen, business objects follow the same sequence of events for creation, retrieval, and updates. Because of this, there s a structure and a set of features that are common to all of them. Although the structure and features are common, however, the actual code will vary for each business object. Due to the consistency in structure, however, there s great value in providing some foundations that make it easier for the business developer to know what needs to be done. Also, there are differences between editable and read-only objects, and between root and child objects. After discussing the features common to all business objects, I ll create templates to illustrate the structure of each type of business object that you can create based on CSLA .NET.

There are some common features or conventions that should be followed when coding any business classes that will inherit from the CSLA .NET base classes. These are as follows: <Serializable()> attribute Common regions Private default constructor Criteria class Let s briefly discuss each of these requirements.

All business objects must be unanchored so that they can move across the network as needed. This means that they must be marked as serializable by using the <Serializable()> attribute, as shown here: <Serializable()> _ Public Class MyBusinessClass End Class This is required for all business classes that inherit from any of the CSLA .NET base classes. It s also required for any objects that are referenced by business objects. If a business object references an object that isn t serializable, then you must be sure to mark its field with the <NonSerialized()> attribute to prevent the serialization process from attempting to serialize that object. If you don t do this, the result will be a runtime exception from the .NET Framework.