andyfrench.info

I couldn’t recall the correct Visual Basic .Net syntax for creating an interface which itself extends other interfaces. So, as a reminder, here it is.

Lets say we have 2 simple interfaces: INameable and IIdentifiable. These interfaces simply require that implementing classes have an Id property and a Name property respectively. Lets also say that we want to define an IReferenceData interface that simply says implementing classes must implement INameable and IIdentifiable.

For comparison lets start with C#:

namespace Domain
{
    /// <summary>
    /// Classes implementing this interface will have a name property.
    /// </summary>
    public interface INameable
    {
        /// <summary>
        /// Gets or sets the name of the entity.
        /// </summary>
        string Name { get; set; }
    }

    /// <summary>
    /// Classes implementing this interface will have an Id property.
    /// </summary>
    public interface IIdentifiable
    {
        /// <summary>
        /// Gets or sets the unique ID of the entity.
        /// </summary>
        int Id { get; set; }
    }

    /// <summary>
    /// An interface to be implemented by reference data types (simple types with 
    /// Name and ID properties).
    /// </summary>
    public interface IReferenceData : IIdentifiable, INameable
    {
    }
}

Now, the same thing in VB.Net:

Namespace Domain
    ''' <summary>
    ''' Classes implementing this interface will have a name property.
    ''' </summary>
    Public Interface INameable
        Property Name As String
    End Interface

    ''' <summary>
    ''' Classes implementing this interface will have an Id property.
    ''' </summary>
    Public Interface IIdentifiable
        ''' <summary>
        ''' Gets or sets the unique ID of the entity.
        ''' </summary>
        Property Id As Integer
    End Interface

    ''' <summary>
    ''' An interface to be implemented by reference data types (simple types with 
    ''' Name and ID properties).
    ''' </summary>
    Public Interface IReferenceData
        Inherits IIdentifiable
        Inherits INameable
    End Interface
End Namespace

Note the separate Inherits statements on separate lines.

Here’s a quick gotcha that got me again today. In C# to get a type we might use code such as the following:

var type = typeof(SomeType);

The equivalent in Visual Basic .Net is:

Dim type = GetType(SomeType)

The closest thing in Visual Basic .Net to a C# static class is a Module (also known as a standard module). In C# a static class is described as follows:

“A class can be declared static, indicating that it contains only static members. It is not possible to create instances of a static class using the new keyword. Static classes are loaded automatically by the .NET Framework common language runtime (CLR) when the program or namespace containing the class is loaded.” *

There is no direct equivalent in Visual Basic .Net but a Module has some properties similar to those of a static class:

• Every module has exactly one instance and does not need to be created or assigned to a variable.
• Modules do not support inheritance or implement interfaces.
• A module is not a type - you cannot declare a programming element to have the data type of a module.
• You can use Module only at namespace level.
• The declaration context for a module must be a source file or namespace (not a class, structure, module, interface, procedure, or block).
• You cannot nest a module within another module, or within any type.
• A module has the same lifetime as your program.
• All a module’s members are implicitly Shared. **

Example in C#:

static class SomeName
{
    public static string SomeMethod1() { return "Value 1"; }
    public static string SomeMethod2() { return "Value 2"; }
    //...
}

Equivalent in Visual Basic .Net:

Public Module SomeName
    Public Function SomeMethod1() As String
        Return "Value 1"
    End Function
    
    Public Function SomeMethod2() As String
        Return "Value 2"
    End Function
    '...
End Module

* Static Classes and Static Class Members (C# Programming Guide) 
** Shared - specifies that one or more declared programming elements are associated with a class or structure at large, and not with a specific instance of the class or structure.

I was thumbing through my copy of SOA Principles of Service Design by Thomas Erl, and thought I’d make a few notes on some of the standout concepts as well as notes picked up from other locations.

As usual this is going to be a work in progress…

OASIS (Organization for the Advancement of Structured Information Standards) defines SOA as:

“A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.”

Principles of Service-Orientation as a design paradigm

Erl describes some of the principles of a service-oriented design paradigm in the following terms:

• Standardised Service Contract
• The purpose and capabilities of a service are exposed by a service contract.
• Service Loose Coupling
• Emphasis should be placed on reducing dependencies between the service contract, its implementation and its consumers.
• Service Abstraction
• Hide the underlying details of a service from its consumers.
• Enables and preserves loose coupling. 
• Service Reusability
• Emphasises the positioning of services as enterprise resources “with agnostic functional contexts”.
• Service Autonomy
• Underlying solution logic needs to have a significant degree of control over its environment and resources.
• Service Statelessness
• “The management of excessive state information can compromise the availability of a service and undermine its scalability and potential.”
• Ideally, services should remain stateful only when required.
• Service Discoverability
• “For services to be positioned as IT assets with repeatable ROI they need to be easily identified and understood when opportunities present themselves.”
• Service Composability
• Services should be capable of participating as effective composition members.

Isolation defines how or when changes made by an operation become visible to other concurrent operations. In other words you can use Isolation levels to isolate a resource for a transaction and protect that resource from modification by other transactions.

Resources are protected through the use of locks. SQL Server decides what locks to take out (and when) by looking at the Isolation Level for the transaction. Lower levels of isolation will allow multiple access to a resource simultaneously but may introduce concurrency related problems (e.g. dirty-reads, data inaccuracy). Higher levels of isolation should eliminate concurrency problems but risk introducing blocking.

Serializable

All transactions occur in a completely isolated fashion.

Places a range lock on the data set preventing other users from updating or inserting rows into the data set until the transaction is complete.

This is the most restrictive of the four isolation levels.

Repeatable read

All data records read by a SELECT statement cannot be changed. The transaction acquires read locks on all retrieved data, but does not acquire range locks.

Locks are placed on all data that is used in a query preventing other users from updating the data. However, new ‘phantom’ rows can be inserted into the data set by another user and will be included in later reads in the current transaction.

Read committed

Records retrieved by a query are not prevented from modification. Non-repeatable reads may occur (data retrieved in a SELECT statement may be modified by some other transaction when it commits). Read locks are acquired on selected data but they are released immediately. Write locks are released at the end of the transaction.

Shared locks are held while the data is being read to avoid dirty reads but the data can be changed before the end of the transaction.

This is the default Isolation Level of SQL Server. It eliminates dirty-reads but other concurrency problems remain.

Read uncommitted

Dirty reads are allowed. One transaction may see uncommitted changes made another transaction.

It is possible to read uncommitted or dirty data but values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction.