Data Transfer Object Pattern Goes VB.NET

Data Transfer Object Pattern Goes VB.NET

Here is a simple example for the Data Transfer Pattern (DTO) Pattern in VB.NET. The task for using this pattern is the following:

The client must not know the details about the structure of business objects on the server side. However, the client must be able to work with all data from the business objects.

We write an example for a business report. The report contains two business objects:

  • ContractObject
  • BusinessPartnerObject

Our solution has a service-oriented architecture and the client gets only ONE object from the service with all datas from both business objects. We call this a Data Transfer Object (DTO).

The DTO looks like this:

Public Class ReportDTO

   Private m_contractname As String    = ""
   Private m_contractdate As Date      = Nothing
   Private m_businesspartner As String = ""

   Public Property ContractName() As String

Get
   Return Me.m_contractname
   End Get

   Set(ByVal value As String)
   Me.m_contractname = Value
   End Set
   End Property

   Public Property ContractDate() As Date

Get
   Return Me.m_contractdate
   End Get

   Set(ByVal value As Date)
   Me.m_contractdate = Value
   End Set
   End Property

   Public Property BusinessPartner() As String

Get
   Return Me.m_businesspartner
   End Get

   Set(ByVal value As String)
   Me.m_businesspartner = Value
   End Set
   End Property
   End Class

And the business objects are here:

Public Class ContractBDO

   Private m_contractname As String = ""
   Private m_contractdate As Date   = Nothing

   Public Property ContractName() As String

Get
   Return Me.m_contractname
   End Get

   Set(ByVal value As String)
   Me.m_contractname = Value
   End Set
   End Property

   Public Property ContractDate() As Date

Get
   Return Me.m_contractdate
   End Get

   Set(ByVal value As Date)
   Me.m_contractdate = Value
   End Set
   End Property


End Class



Public Class BusinessPartnerBDO
   Private m_businesspartner As String = ""

   Public Property BusinessPartner() As String

Get
   Return Me.m_businesspartner
   End Get

   Set(ByVal value As String)
   Me.m_businesspartner = Value
   End Set
   End Property

   End Class

The client is now able to fill the DTO with necessary data and send it back to the service. The service has an assembler that is able to transport the date from the DTO to the expected business object and the reverse.

And, here is our assembler:

Public Class ReportAssembler

   Public Shared Function MakeContractObject(ByVal dto As ReportDTO) _
          As ContractBDO


   Dim obj As New ContractBDO
   obj.contractname = dto.contractname
   obj.contractdate = dto.contractdate
   Return obj

   End Function

   Public Shared Function MakeBusinessPartnerObject(ByVal dto _
          As ReportDTO) As BusinessPartnerBDO

   Dim obj As New BusinessPartnerBDO
   obj.businesspartner = dto.businesspartner
   Return obj

   'Reverse Methods go here

   End Class

The service call from the client side looks like this:

Public Class ReportService

   'Example for writing the objects from the DTO
   Public Sub WriteObjects(ByVal dto As ReportDTO)

   Dim trans As Transaction    'Example only

   Dim objContract As ContractBDO = _
       ReportAssembler.MakeContractObject(dto)
   Dim objBusinessPartner As BusinessPartnerBDO = _
       ReportAssembler.MakeBusinessPartnerObject(dto)

   trans.AddWriteObject(objContract)
   trans.AddWriteObject(objBusinessPartner)

   trans.Execute()

   End Sub

   End Class

The advantage is that the client gets only one object and only the service task has to fill the two database relations. The client is always stupid and knows nothing about the data structure in the background.



Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • On-demand Event Event Date: September 10, 2014 Modern mobile applications connect systems-of-engagement (mobile apps) with systems-of-record (traditional IT) to deliver new and innovative business value. But the lifecycle for development of mobile apps is also new and different. Emerging trends in mobile development call for faster delivery of incremental features, coupled with feedback from the users of the app "in the wild." This loop of continuous delivery and continuous feedback is how the best mobile …

  • As mobile devices have pushed their way into the enterprise, they have brought cloud apps along with them. This app explosion means account passwords are multiplying, which exposes corporate data and leads to help desk calls from frustrated users. This paper will discover how IT can improve user productivity, gain visibility and control over SaaS and mobile apps, and stop password sprawl. Download this white paper to learn: How you can leverage your existing AD to manage app access. Key capabilities to …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds