1
\$\begingroup\$

I am developing a large .NET app. The previous developer used Martin Fowlers Transaction script design pattern. Please see the code below:

Public Class TypeStudent
    Private _Name As String
    Private _Type As String 'Undergraduate or postgraduate
    Public Property Name() As String
        Get
            Return _Name
        End Get
        Set(ByVal value As String)
            _Name = value
        End Set
    End Property

    Public Property Type() As String
        Get
            Return _Type
        End Get
        Set(ByVal value As String)
            _Type = value
        End Set
    End Property
End Class


Public Class Students
    Public Sub Add(ByVal typeStudent As TypeStudent)

    End Sub

    Public Sub Remove(ByVal typeStudent As TypeStudent)

    End Sub

    Public Sub Enrol(ByVal typeStudent As TypeStudent)
        If typeStudent.Type = "U" Then
            'Undergraduate specific logic
        ElseIf typeStudent.Type = "P" Then
            'Postgraduate specific logic
        End If
    End Sub
End Class

Notice that there is one Student class and Student.Enrol has to check the type of student before executing the appropriate logic. Now please see the refactored code below, which uses a domain model approach:

Public Class Student
    Private Name As String
    Private Type As String

    Public Sub Add()

    End Sub

    Public Sub Remove()

    End Sub


End Class

Public Class Undergraduate
    Inherits Student

    Public Sub Enrol()

    End Sub

End Class

Public Class Graduate
    Inherits Student

    Public Sub Enrol()

    End Sub

End Class

Notice that Undergraduate and PostGraduate has its own implementation of Enrol. I want to refactor more code so that it is like sample B to make it more reuseable and maintainable. My question is; is it a bad idea to mix and match domain logic patterns in the same application i.e. part of the app written using Transaction Script and another part using domain model?

\$\endgroup\$
2
\$\begingroup\$

I don't think that there is inherently anything "wrong" with having multiple patterns like this in a single application, especially during a refactoring exercise. I would strongly suggest documenting the patterns that you are changing from and to and the reason for the modification so that future developers understand what is happening.

I would make one substantial modification to your proposed implementation, however: define Enrol at the Student level as an Overridable method.

If there is no default implementation for all students, change Overridable to MustOverride. This will in turn force Student to be declared as MustInherit, but this is ok if you can only call Enrol on instances of Undergraduate or Graduate.

\$\endgroup\$
3
  • \$\begingroup\$ Thanks. +1 for the last paragraph. Have you mixed and matched domain layer patterns I.e. transaction script and domain model, in your own apps? \$\endgroup\$ – w0051977 Jun 3 '13 at 21:54
  • \$\begingroup\$ Yes, we have done this quite a bit. In some cases, we use the transaction script intentionally to make the classes easier to consume by external users (XML or json serialization, for example, where the method differences don't matter). For internal-only classes, our preferred pattern is domain, but we do have a lot of legacy code that has not been transitioned yet (if it isn't broken...). \$\endgroup\$ – competent_tech Jun 3 '13 at 22:58
  • \$\begingroup\$ Thanks. How does transaction script make serialisation easier? \$\endgroup\$ – w0051977 Jun 4 '13 at 6:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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