- A Step Toward Realism
- Overview
- New Architecture Code Examples
- The Usual Type of Client-Side Code
- A Couple of Tweaks that Help Performance
- Collapsed Objects
- Statuses in One Single Byte
- Object Vector
- NonSerialized()
- Using "Dumb" Collections
- Another Struggle with Guids
- Oops, Maintainability Must Be Lost!
- And a Few Tweaks Not Applied Yet
- A New Test Application
- Results of the Throughput Tests
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
New Architecture Code Examples
As usual, we will take a look at some code samples, both from the server-side and from the client-side. Also as usual, I start from the server-side, but I have a lot more code to cover. First is the code in the class for the Service layer. As you can see in Figure 3, the class is called FetchingOrderInformation__NewArch.
)
Figure
3 The Service layer class of the week.
NOTE
Do you remember my saying last time that I thought I should use entity objects for parameters when doing a fetch by key? As a matter of fact, I have changed my mind. One reason is that each time an object is deserialized, you get a new object. Another reason is that it feels pretty wasteful to send a complete but empty object over the wire just to let the server-side receive the key for the row to be fetched in the database. I therefore find it okay to use plain values instead. But it's nice to not use them as Integer, for example, but as a custom valuetype so you encapsulate the datatype, if possible.
Also, an attribute such as CustomerId shouldn't be used in an Order class. Instead, the Order class should have a Customer instance. Anyway, I haven't done that in the object model used in the article because it would make the tests too much like comparing apples and oranges. Also, when using full-blown objects instead, it gives more functionality—and if you want that functionality, you probably find it okay to pay for it, too.
Listing 1 shows the code for FetchOrderAndLines() from the Service layer.
Listing 1—Service Layer Code
Public Function FetchOrderAndLines _ (ByVal id As Integer) As NewArchOrder Return POrder.FetchOrderAndLines(id) End Function
If you compare the code in Listing 1 with code shown in the previous articles, you find that I delegate all work regarding fetching and instantiating objects to a class called POrder, which lives in the Persistence Access layer. The responsibility of POrder is to encapsulate everything about the database schema regarding orders so that no knowledge about it is found in the Service layer or the Domain Model. The POrder is an implementation of the Data Mapper pattern. (See Fowler, Patterns of Enterprise Application Architecture.)
The FetchOrderAndLines() method of the POrder class is shown in Listing 2.
Listing 2—Persistence Access Layer Code
Public Shared Function FetchOrderAndLines_ (ByVal id As Integer) As NewArchOrder Dim aUnitOfWork As New CommandUnitOfWork() _AddFetchOrderAndLines2UnitOfWork(id, aUnitOfWork) Return _InstantiateOrderAndLines(aUnitOfWork) End Function
The code in Listing 2 is again very different from what was used in previous articles. What's going on here is that I use an implementation of the Unit of Work pattern. (See Fowler, Patterns of Enterprise Application Architecture.)
You can think of the aUnitOfWork instance as a collector for collecting all information about what should be done against the database. That collecting work has been factored out to the _AddFetchOrderAndLines2UnitOfWork(), which we will look at in a minute. The second task for aUnitOfWork in Listing 2 is to execute statements against the database, and that is factored out to _InstantiateOrderAndLines().
NOTE
The biggest benefit of the Unit of Work pattern is when I execute updates against the database and need an explicit transaction because the transaction will be "compressed" to the shortest timeframe without delays within. Even so, I benefit from the Unit of Work here, too, because it's also a helper for database access that encapsulates a lot of ADO.NET details from the bulk code.
In Listing 3, you find the implementation of _AddFetchOrderAndLines2UnitOfWork().
Listing 3—_AddFetchOrderAndLines2UnitOfWork()
Private Shared Sub _AddFetchOrderAndLines2UnitOfWork _
(ByVal id As Integer, ByVal unitOfWork As UnitOfWork)
With unitOfWork
.AddSprocCall(Sprocs.FetchOrderWithLines.Name)
.AddParameter(Sprocs.Parameters.Id.Name, id, _
Sprocs.Parameters.Id.Size, False)
End With
End Sub
In Listing 3, you see that a stored procedure call was added to the unitOfWork, and a parameter was set. There was not very much information about what to do in this case. Anyway, it's clean and simple.
Listing 4 shows the implementation of _InstantiateOrderAndLines().
Listing 4—_InstantiateOrderAndLines()
Private Shared Function _InstantiateOrderAndLines _
(ByVal unitOfWork As UnitOfWork) As NewArchOrder
Dim anOrder As NewArchOrder
Dim aResult As IDataReader = _
unitOfWork.ExecuteReturnDataReader()
Try
aResult.Read()
anOrder = _InstantiateOrderHelper(aResult, False)
aResult.NextResult()
Do While aResult.Read
anOrder.AddOrderLine _
(_InstantiateOrderLineHelper(aResult))
Loop
_EndInitializeFromPersistence(anOrder)
Finally
aResult.Close()
End Try
Return anOrder
End Function
In Listing 4, a lot more work is done. Here, the unitOfWork is told to execute the statement against the database. Then, once again, more work has been factored out. The work for instantiating a single order and a single order line is found in _InstantiateOrderHelper() and _InstantiateOrderLineHelper(). So, the DataReader is first sent to _InstantiateOrderHelper(); then it's sent to _InstantiateOrderLineHelper() to get the second resultset processed. When the DataReader (and its two resultsets) are processed, the DataReader is closed, and the newly instantiated Order is returned.
_InstantiateOrderHelper() and _InstantiateOrderLineHelper() are pretty similar to each other, so I think it's enough to show _InstantiateOrderHelper(), which is shown in Listing 5.
Listing 5—_InstantiateOrderHelper()
Private Shared Function _InstantiateOrderHelper _
(ByVal dataReader As IDataReader, _
ByVal expanded As Boolean) As NewArchOrder
Dim anOrder As New NewArchDomain.NewArchOrder _
(Guid.NewGuid, expanded)
_StartInitializeFromPersistence(anOrder)
With anOrder
.Id = dataReader.GetInt32(Sprocs.OrderColumns.Id)
.CustomerId = dataReader.GetInt32 _
(Sprocs.OrderColumns.CustomerId)
.OrderDate = dataReader.GetDateTime _
(Sprocs.OrderColumns.OrderDate)
End With
Return anOrder
End Function
In Listing 5, I set the anOrder instance in a mode in which it is initialized from persistence so that the dirty support isn't "started," and possible validation rules aren't checked. Then, I set the properties by moving the data from the DataReader to the entity instance. Note that I don't end the initialization mode in Listing 5. That isn't initialized until the complete order instance, including its order lines, is done (late in Listing 2).
As shown in Listing 5, I used Guid.NewGuid instead of fetching a Guid from the database. The reason is because the architecture currently supports Guids only for primary keys, but the database that I used for the prior tests uses INT+IDENTITY for primary keys. Therefore, I just fake a value here.
Also note that I used IDataReader in the code above instead of SqlDataReader as before. That feels much cleaner and better!