Scott Stewart

asp.net mvc RenderUserControl controlData

I've had a little trouble getting data from a asp.net mvc ViewPage to a ViewUserControl. The html extensions toolkit provides a RenderUserControl method that has an overload that allows for "controlData" to be explicitly sent from the ViewPage to the UserControl. I much prefere the approach of explicitly sending the required data to a user control instead of assuming that it will implicitly grab it from somewhere. I've found a few things that make this process work better for me. First, I send the data to the ViewUserControl as an anonymous type, and secondly all of my view user controls inherit from a base AppViewUserControl that I create for the application. In this base class I override a few ViewData methods to get over what looks like a bug with the current implementation of the the HTMLExtensionUtility. I was running into a problem where the "ViewData" property on the ViewUserControl should be of type object, and instead it is of type System.Web.Mvc.ViewData, and so can't be treated as an anonymous type.

So, in my base ViewUserControl class I add the following:

Partial Public Class AppViewUserControl
    Inherits System.Web.Mvc.ViewUserControl

    Private _ViewData As Object
    Protected Overrides Sub SetViewData(ByVal viewData As Object)
        MyBase.SetViewData(viewData)
        _ViewData = viewData
    End Sub

    Public Overloads ReadOnly Property ViewData() As Object
        Get
            Return _ViewData
        End Get
    End Property

End Class

There is probably a better way to do this, and this may have side effects that I haven't hit yet. But it seems to do the trick for me. Basically, all I'm doing is duplicating the storing and retrieving of the passed view data from the page to the control, so that the control's view will see the data as type object.

Once this is done, then from a mvc ViewPage, we can explicitly pass the required UserControl data as an anonymous type like this:
<%=Html.RenderUserControl("~/Views/Shared/Status.ascx", New With {.Status = Status, .Message = Message})%>

Obviously, Status and Message are just examples in this snippet of code of data that is local to the ViewPage, and you would use your own data and properties probably from the page's local ViewData.

With this in place, then I'm able to do something like this in my ViewUserControl to use this data:
<div id="system_status"><%=ViewData.Message%></div><%=ViewData.Status%></div>

I personally like the idea of explicitly passing required data from the ViewPage to the ViewControl, similiar to how rails allows a render :partial, with a :locals symbol to tag the hash of local data for the partial.

asp.net mvc view user controls

I was having some problems getting the html helper extensions available to a custom view user controls in a asp.net mvc app. I noticed that when using the ide to "add new item" > "mvc view user control", the default behavior is to create a view with code behind. And even though the code behind class inherits from Mvc.ViewUserControl, the html helper extensions weren't available to the user control. After thinking about it for a second, I realized that I'm not planning on using code behind in my view user controls. I'm really just using these to encapsulate some common html, and any data needed will be passed as view data by the page using the control. So, I dropped the code behind and changed my @Control directive to inherit directly from System.Web.Mvc.ViewUserControl and viola, the html helper extensions were now available to the user control. Hmm. Well it works for me, I have no need for the code behind, but if I run into a situation where it becomes necessary I'll need to think about why the html extensions methods dont' appear available with the default code behind/inherit approach.

project/solution prep

Some solution/project setup stuff that I normally put in place when starting a new project...
Folder structure:

bin (all projects under src\app build here, but not test projects)
docs
lib

custom (in house stuff)
common (nibernate, log4net, castle, etc.)

script (any dev script stuff, maybe build related, maybe sql script, maybe ruby/rake tasks)
src

Proj1
Proj2

test

Proj1.Test
Proj2.Test
TestRunner

tools

nunit
rhinomocks, etc.

Once the folder structure is ready, I add a TestRunner project (and make it the startup project in vs) to the test folder. It only has one purpose; a proxy to launch NUnit. To wire this up, in the TestRunner project/compile tab under "start external program" add this: tools\nunit\nunit.exe
Then I create a nunit project file that should be named the same as the runner project. So, in this case I would create a TestRunner.nunit file that lists the projects to be tested. In this case it might look like this:
<NUnitProject>
<Settings activeconfig="Debug" />
<Config name="Debug" binpathtype="Auto">
<assembly path="bin\Debug\Proj1.Test.dll" />
<assembly path="bin\Debug\Proj2.Test.dll" />
</Config>
</NUnitProject>
To get the test project's dll's in the TestRunner's bin\Debug, I just reference them in the TestRunner project. Alternatively, you could just reference thier respective build paths directly in this config file.

Then add a config file to the TestRunner project named the same as the Project and the nunit projet file (without the .vbproj and .nunit respectively of course). - in this case TestRunner.config.
Nunit will load a config file with the same name as the project file. So, you could also get along with naming them NunitTests.nunit and NUnitTests.config respectively.

MonoRail Project template and Web Application Project add-in

If you are thinking about giving MonoRail a try for ActionPack inspired .net web development, you probably should install the Visual Studio Web Application Project Option and add-ins first.

The MonoRail msi includes a few Visual Studio templates (Castle Active Record Project, and Castle Monorail Project). When attempting to use the template to create a new project of type Castle Monorail Project, you will need to be able to support Web Application Projects (not just the standard default .net 2 Web Projects). If the Visual Studio Web Application Projects add-ins are not installed (like the machine I was trying out MonoRail on), then when creating a new Castle Monorail Project from the template, you will probably get an error saying that you are attempting to open an unsupported project type (MRProject.csproj).

asmx endpoint (prior to WCF)

Generally, when creating a service to be exposed as a web service, I have built the entire service project(s) (including datacontract/entity classes) outside of any web project, in a separate solution. These projects can then be built and tested without any web project getting involved. I then usually create a separate web project, that acts solely as a http end point, and which references and uses the actual web service project(s) . To facilitate this, there is a 1:1 mapping in the asmx code behind which simply defines the webmethod and passes through or calls upon the real service class. What a waste of time and useless code.

When using the Patterns & Practices Web Service guidance, I noticed that just like I have always done, the real service classes are created in their own projects outside of the scope of a web project (for numerous good reasons), but I noticed that in the actual web project classes there was no code behind, and therefore no 1:1 mapping of each web method to the real service method. As simple as the explanation is, I scratched my head for a few minutes trying to determine how the actual service classes were getting invoked? In the words of Homer, "Doh!" In the Asmx @Webservice directive there is no codebehind attribute, and the class= attribute just references the fully qualified class name that implements the actual service methods. This requires the actual service project references system.web, and also requires that the public web method attributes are marked accordingly. But this is fine because the goals of separating the service implementation from the end point project are still accomplished, all without the useless 1:1 mapping in the codebehind.

Sometimes its the simple things. Oh well, I finally realize this now that .Net 3 is available and WCF changes the way we declare endpoints altogether. But, I wish I had realized this simple asmx endpoint trick a while back : -)

Asynchronous web methods used with @Page Async=True

Its seems most of my development these days involves some form of modular parts assembled at runtime in Windows SmartClient apps, or at Page Load time in customizable web part portal applications. In web portal apps, that are built out of independent web parts, page performance can degrade linearly with the number of parts included on any one page. Generally, if each of these parts is treated as a true module or smart web part then they are usually each responsible for getting their own data. Because of this, I find myself doing a lot more asynchronous work during page processing so that all the parts can come together in parallel within a reasonable amount of time. The trick is to not tie up the main worker thread as it waits for your async parts to finish, so that it can go back and handle other page requests. Asp.Net 2.0 enables this process with the Async=True page attribute. However, there is a little additional magic that happens behind the scenes when using web services via proxies that were created with Asp.Net 2.0 web references.

When adding a web service reference to .Net 2.0 Asp.Net app, you may notice that for each web method there is a "async" method also created in the reference file. Since .Net 1, we have gotten both the standard synchronous method implementation, and also the corresponding Begin/End async methods (following the standard IAsyncResult pattern). However, in .Net 2.0, web references also create a third choice, which uses a delegate callback pattern. When this async method is used to populate a control in conjunction with a web page marked with the Async="True" Page directive, some interesting stuff happens. Behind the scenes, when the async version of the method is called on the web proxy, "InvokeAsync" of the proxy's SoapHttpClientProtocol base class is called, which in turn registers this call with .Net 2.0's AsyncOperationManager. If you have been using the Async=True page directive in Asp.Net 2, you are probably familiar with calling Page.RegisterAsyncTask to do some async work. For those not familiar with this, Async=True will allow a page to process up to pre-render, but then it will relinquish its main Asp.Net processing thread, until it's registered async tasks finish. The powerful thing about using the new async web methods, is that this call to RegisterAsyncTask is wired up implicitly for you. So, you mark a page with the Async=True attribute, call upon the asynchronous version of the web method, and the RegisterAsyncTask is wired up for you.

Fritz explains this awsome feature in detail in his June Extreme Asp.Net article.

Smart Clients, Click Once and MAGE

If you've developed Smart Client applications, especially of the CAB/SCSF flavor, you've probably also thought about Click Once for deployment. One of the big attractions of this architecture is the loosely coupled modules that can be independently developed and then dynamically included at runtime. All this magic however causes one to ask "how do I get all of these modules/assemblies together into a single Click Once deployment?" The answer is the Manifest Generation and Editing tool (available in both command line mage.exe and ui mageui.exe)

There are already plenty of good articles/blogs on how to use MAGE and integrate into your build process. Here are a few that helped me along the way:

Deploying a CAB/SCSF Application with ClickOnce

The fix for MAGE impairment

Administering ClickOnce Deployments

Smart Client Factory, not your grandmother's old P and P

Until 2 weeks ago, it had been about 8 months since I had an opportunity to look at any offerings from the Patterns & Practices group. My how things can change in 8 months! Back at the beginning of the year I gave the Composite UI Application Block (CAB) Smart Client framework a first look. It is quite an impressive framework for building Windows forms Smart Clients. But, it is one of those things that needs more then a first look to really come to grips with it. A quick Google search on "CAB Complexity" will give you a good idea; here are a few good links: DevHawk (from 11/2005) "However, I can't shake the feeling of how complex this stuff is", Sam Gentile's - CAB Smart Clients in an Agile world part 1 while discussing his initial thoughts "...Yet CAB’s seeming complexity had overwhelmed me..." Additionally, right on the P & P CAB home on gotdotnet in the overview section it clearly says "Ever wondered what would the architecture and design of a complex UI would look like?" I guess they weren't kidding! I remember back when I first read this I had said to myself "man, I've seen enough complex UI architectures, what I really want to see is a simple one! But, I digress...

Once you come to grips with CAB, it is a pretty impressive framework, and even if you don't have an opportunity to put it to use right away, there is some well written code and UI architecture guidance that can be learned by giving this thing some time. The overall design is based upon 3 major goals: 1) dynamically loading application modules at run time, 2) separation of development concerns, 3) achieving code re-use by providing common techniques for loose coupling modularity. I'm not sure I'm sold on the success of all 3 goals, but I'll talk more about that below. There is however, an awful lot about CAB that I like: The Event Broker Pub/Sub approach, Object Builder and its injection magic using "service dependency" attributes and the modularity in general like the UIExtensionSites for allowing modules to add their own stuff to toolbars, menu, etc. Additionally the guidance that developed around the use of WebService agents, proxies, commands and implementing asynchronous background calls with specified timeout was precious. This is just a fraction of stuff that comes immediately to mind.

Now jump to the present time (remember CAB was released around 12/05) and suddenly we have 3 Software Factories (Smart Client Software Factory, Mobile Client Software Factory, and the latest Web Service Software Factory all available to assist, guide and generate baseline framework code for us! Man a lot has been happening at the Patterns and Practice group this year. So far, I've only had time to dig into the Smart Client Software Factory, and again it is quite impressive. If you have already used CAB, I guess you can look at The Smart Client Software Factory as a big integrated wrapper and guidance package around CAB. Besides for CAB, it integrates the Enterprise Library (Caching, Exception Handling, Logging, etc.), Guidance Automation Toolkit and Guidance Automation Extensions (enabling framework generation and code automation and recipies), as well as a couple of sample applications to demonstrate Smart Client approaches. Wow, some good stuff. I've slept little over the past two weeks feeling like a kid in a candy store since I started digging back into the P&P offerings. Besides for architecting solutions and writing code myself, I love reading and learning about other people's approaches to solving the same problems I've worked toward solving myself. You end up solidifying some of your approaches (and feeling good about seeing others doing things the same) and yet questing other approaches (some yours some theirs), and in the end grow from the experience.

Despite all this goodness, I have to admit that I initially put down CAB at the beginning of the year, frustrated not by the complexity, but by of all things, some of the guidance around business logic and lack of domain logic. And, as I've been digging into CAB again now, under the new covers of the Software Factory, I've found myself a number of times feeling this same difference of opinion on business logic. Difference of opinion are to be expected. It is a given. It's just that I'm so passionate myself about domain specific business logic encapsulation that it's a tough elephant in the corner to ignore when reading through all the great documentation, help files and demos. I mean there is so much there, so much great thought given to complex problems, how can domain business logic be so missing? Maybe its me? A quick search on CAB Business Logic doesn't turn up much of relevance.

My problem is twofold, 1 part difference of option on the term "business logic", which comes through loud and clear bullet point after bullet point in documentation, and second is a bit of difference of option on architecture associated with domain business logic.

First, lets look at the difference of opinion on the definition of "business logic". All of the CAB documentation seems to consider UI specific design, namely web forms, win forms, a Windows TextBox or a mobile control drop down, etc. all part of "business logic" and I don't. This is really ironic too, seeing as it is clearly stated again and again that one of the core tenets of CAB and the Smart Client Factory is to separate UI concerns from business concerns. However, it seems that they only really consider the job of creating the outer shell of a Smart Client application (main work space, toolbars, status bar, menu, etc) to be real UI, and all other application UI like stuff (forms, controls, etc.) to be "business logic". I'm sorry but I find myself scratching my head in WTF fashion when I read this over and over throughout CAB docs, blogs, help files, etc. For an example, look under the section entitled "Benefits" and "Separation of Concerns" in the Overview of the Composite UI Application Block and you come across this little nugget: "Applications built with the Composite UI Application Block have a design that delineates the difference between writing shell logic (requiring expertise in Windows Forms, user controls, and appearance and behavior), infrastructure components (built only once per application or re-used from other applications), and business logic (the user interfaces, logic, entities, and service agents of the specific application). "

OK, you might think I'm taking this one little inclusion of "user interfaces" with business logic a bit overboard, but this common rational and description of "business logic" is embedded over and over in quite a lot of CAB reference material. The problem is that one of the goals of CAB is to allow modular design, where each module is like a tiny application that is plugged into an overall shell application, and each of the modules added all up represents the business logic of the overall application. Now, in defense of CAB documentation, I don't believe I stumbled over anything that explicitly said that you shouldn't take things a step further and extract the real Domain specific business logic and business behavior (read no UI) out into yet another septate assembly and then reference that in your module assembly, but then again it never seems to be suggested either, and to me this is just enterprise architecture 101. Instead, everything about CAB suggest that all "business logic" exist in the module assembly. Keep in mind that this module assembly is designed specifically with a given Smart Client Shell in mind that it will be loaded into, and the module assembly contains all the UI forms and controls, etc., etc. etc. Once again, in CAB defense, all of the documentation and the CAB framework in general is built around the idea that the pieces of the module will be built using good UI separation of concern Modal View Presenter patterns. But it takes a little more then a separate "presenter" class or supervising controller architecture alone for me to feel like we are ready to start talking about coding domain specific business logic yet. At best, when we are in the very UI world of views, presenters and supervising controllers we are talking about wiring up specific UI use cases to well defined Domain Use Cases, but we definely shouldn't be talking about actually encapsulating and coding this Domain Business should we?

And this is where we come into my second difference of opinion, and this is really just plain old architecture difference of opinion and different architects are going see this from different perspectives, but I'm unfortunately talking about a Business Object versus Business Entity difference of opinion. Everything coming out of the P&P factories seem to all take the business entity approach. This type of architecture generally involves light weight classes, really just exposing property getter and setters, taking the shape of pieces of domain data, being acted upon in pipeline like fashion and cross cut by vertical aspects like security. However, generally the entities themselves encapsulate no behavior, but just data. Behavior exists in supervising controllers, and presenters, and helpers but is separate from the "entity". This is definely an architecture direction that is growing more and more in popularity. Like all architectural direction however, it has its place and can often be a wise choice, but it is not the only one and isn't always the best choice.

The problem is that this behavior free entity approach works fine in most small demo applications, but once you really get into building true line of business applications, the business logic starts leaking out everywhere. Lets assume you have an entity that represents the data associated with applying for a loan. And lets suppose that you have a field called ApplicationDate and a field called RequestedFirstPaymentDate, and lets suppose that the Domain you are working in has a rule that says the Requested First Payment Date must be greater then 30 days but less then 45 days from the Application Date. Following a CAB recipe where would you put this logic? In the presenter? In a WorkItem? In the loan service? Well in my opinion the answer is "None of the above!" It doesn't even belong in the CAB module to begin with. The CAB is all about UI as in "Composite UI Application Block" This domain specific logic belongs in a separate Domain Object and project! The only thing the module's presenters or controllers should be responsible for doing is wiring up to the Domain Object's exposed interface for acknowledging this business rule. But definely the rule should not belong in the module. What if you also build a Mobile application using the Mobile Software Factory, and you also want to expose a loan processing web service to some third party resellers. Do you code this same business rule in each respective application. I hope not.

The CAB Smart Client application is dynamically modular by design, and can be expanded nicely over time in true loosely coupled like fashion, but each module that it loads is specifically built for that particular Smart Client application. In other words, the modules are UI specific. They are built knowing that their shell application is a windows application so that they can display maybe a windows forms or a windows user control when acted upon. And they should be built with the goal of solving that particular UI application use case. They need to know that there is a menu in the shell called "MySmartClientAppMenu" (or enter name here) so that they can add commands to the menu. The modules are not designed to be used in multiple places; i.e. I would not re-use a windows SmartClient CAB module in a web application, or within a web service being built to expose the same "Business Logic" to other applications. So, these modules have no real right or place to contain "business logic".

Overall, I am amazed by what I have seen with the Software Factory, including CAB, the GAT/GAX and general guidance. It is great, great stuf. Additionally, despite the fact that there is no real guidance toward this "practice and pattern" there is nothing actually stopping me from building a great Smart Client Application, using CAB just as it is, and taking advantage of GAT/GAX, while at the same time creating separate Domain libraries for business logic. As a matter of fact, I think I will : - )

compact framework at tvug.net

I just got in from tonight's local .net user group, Tech Valley .Net, where Shawn Gwin did a nice job of presenting a high level introduction to using the .Net 2.0 Compact Framework. I've never taken the time myself to look at developing with the compact framework, but thanks to Shawn I feel like I could at least get up and running pretty quickly if need be. Shawn outlined a brief history of developing with the compact framework, using and switching between emulators, and strategies for synchronizing data. He coded up a small demo app for the purpose of the presentation that involved a fictional bicycle delivery service that recorded delivery info and then synch'd up at the end of the day. Shawn discussed some of the pros and cons between using SQL Merge Replication and Remote Data Access (RDA), and demonstrated some sample RDA code within the bicycle app.

If you are a .Net developer living in or around the Albany, NY area, you should really consider giving the meetings a try. They are held on the second Tuesday of every month and besides for interesting topics like using the .Net Compact Framework, they usually involve some pizza, door prizes, local job posting information, and a fun relaxed atmosphere. See you at the next meeting!

BO with DAL, hold the DTO

Generally, when an architecture decision has been made to include Business Objects that utilize a separate dedicated Data Access Layer (DAL), completely external from that of the Business Object, there is one of two basic designs we generally see followed for data retrieval. Either the DAL returns some sort of data structure (hash table, array, custom data structure), or xml, etc. which is generally serving the purpose of a Data Transfer Object (DTO), or the business object is handed back a direct stream (i.e. data reader) which it (the BO) then uses to populate itself. For this discussion, I'm excluding the cases of ORM approaches and that of the business object directly encapsulating data access code.

While the two basic approaches (DTO or returned stream) used between a BO and DAL are widely prevalent in an awful lot of systems (I too have taken one of these two approaches in many circumstances) they are not the only means to accomplish this task. If the data layer is utilizing a data reader, Its seems a waste to package up its results into some DTO only to be passed immediately, perhaps in process, to the BO, then only to be immediately unpackaged by the BO (i.e. mapped on to the BO's member variables). However, if you have already made a decision to separate BO and Data Access code, then returning a data reader, while nice and fast, can have the negative effect of implicitly coupling your BO back to your data layer in a way that requires your BO to know how to read it's data off of the stream. In other words, it can cause the BO to know about things like db column names or ordinals so that it can read it's data ; i.e. customer.name = dr.GetString(2) or customer.name = dr.GetString(dr.GetOrdinal("Customer_Full_Name").

If you have already made a decision to separate BO and DAL then it should be obvious why this decision is implicitly coupling the two back together. So, if you have made the decision to separate the two, then separate the two, and only allow the data access mapping stuff (like db column names) to live where they belong (in this case), in the DAL and not in the BO. So, that leaves us with choice of instantiating and populating a DTO in the DAL, and returning this to the BO. Right? Wrong. There are other ways of getting this data inside the BO, without a DTO and without coupling the BO back to DAL stuff like DB column names on data readers.

Delegates and asynchronous callbacks come in very handy for this kind of work. The basic idea is that the BO calls upon the DAL to fill some data, but instead of getting back a DTO or stream it gives the DAL a handle to a method to be called when the DAL has the data available. The method signature (delegate) can be defined in the DAL (or better yet the interface which the respective DAL implements) and this allows you to keep DB like stuff completely in the DAL, and eliminates the need for explicit DTO creation simply for the purpose of getting the data from the DAL back into the BO. It also allows the BO to do with this data as it will, privately as it should. The DAL simply invokes the callback handle with the predetermined signature, perhaps passing the data results directly off the data reader, all without creating a DTO.

Here is an over simplified example of this type of approach:

Public Interface ICustomerDataAdapter

    Delegate Sub DataAdapterHandlerDelegate(ByVal ID As Integer, ByVal Name As String, ByVal Addresss As String, ByVal Phone As String)

    Sub FillCustomer(ByVal DataAdapterHandler As DataAdapterHandlerDelegate, ByVal CustomerID As Integer)

End Interface

Public Class CustomerSQLDataAdapter
    Implements ICustomerDataAdapter

    Public Sub FillCustomer(ByVal DataAdapterHandler As ICustomerDataAdapter.DataAdapterHandlerDelegate, _
                                         ByVal CustomerID As Integer) Implements CustomerDataAdapter.FillCustomer

        Using cn As Data.SqlClient.SqlConnection = New Data.SqlClient.SqlConnection(connectionString)
            Using cm As Data.SqlClient.SqlCommand = cn.CreateCommand
                cm.CommandType = Data.CommandType.StoredProcedure cm.CommandText = "getCustomer"
                Using dr As Data.SqlClient.SqlDataReader = cm.ExecuteReader
                   ' Here is the callback into the Business Object
                    DataAdapterHandler.Invoke(
                        dr.GetInt32(dr.GetOrdinal("CustomerID")), _
                        dr.GetString(dr.GetOrdinal("Customer_FullName")), _
                        dr.GetString(dr.GetOrdinal("Customer_FullMailingAddress")), _
                        dr.GetString(dr.GetOrdinal("Customer_HomePhone")))
                End Using
            End Using
        End Using
    End Sub

End Class

Public Class Customer
    ' All the business logic, properties, methods, etc.
    Private mID As Integer
    Private mName As String
    ' etc.

    Private Sub RetrieveCustomerData()

        ' you probably want an abstracted factory call to instantiate the respective Adapter instance
        ' and not directly instantiate as here; thus allowing good stuff like unit test adapters to be
        ' swapped in and out with real DB adapters.
        Dim da As ICustomerDataAdapter
        da = New CustomerSQLDataAdapter

        da.FillCustomer(AddressOf DataAdapterHandler, mID)

    End Sub

    Private Sub DataAdapterHandler(ByVal ID As Integer, ByVal Name As String, ByVal Addresss As String, ByVal Phone As String)
        'populate internal fields, such as:
        mID = ID
        mName = Name ' etc.
    End Sub

To sum up, if you have already taken the effort to separate BO and DAL, then don't feel that the only way to get data back onto/into the BO is via an explicit DTO, and also don't feel that you have to sacrifice some separation of duties by requiring the BO to know how to get data directly off of a data reader. In most cases, the decision to use an explicit DAL DTO can be internal to the respective data adapter when needed, or based on other architecture decisions.* In the above example, there is no DTO and the BO doesn't know anything about db field names. There is an explicit contract that the CustomerDataAdapter exposes as to the signature of its FillCustomer method. However, the column names in the DB are all encapsulated in the specific SQLDataAdapter instance and do not seep into the BO. The DB column name could change and only the DAL code that access this field would need to be modified, not the dataAdapter fill signature. The delegate signature, and therefore the BO can remain untouched. Additionally, the BO doesn't need to expose any public FillMe methods or implement any IFillable interface (both of which are completely inappropriate IMHO). Instead the BO encapsulates the logic of populating its internal fields within its own private method, and it is opting to pass the address of this method to the data layer. So, the data layer does its sole responsibility thing (data access) as it should and doesn't know anything about the BO, or how the BO is going to use the data in the delegate signature. Additionaly, the BO doesn't know anything about how the data layer is getting the data arguments to the handler method, and it is still ultimately in charge. It privately calls the fill method, and it privately gives the handle of the appropriate method to handle the results. The data adapter can be easily swapped out with a unit test data adapter (or for any other purpose, i.e. multiple DB types) and there is nothing coupled (including implicit coupling via DB field names used to read data).

* For example, in the code above I included CustomerSQLDataAdapter that directly used a SQL DataReader, however, there could be another CustomerXYZDataAdapter that can't directly use a SQL Connection and Data Reader, and so internally it might utilize a DTO between some other component and or process, or perhaps a web service. But once it receives the DTO, or the web service results, it is able to invoke the same DataAdatperHandler callback.

Identity demands pass in full trust scenarios

StrongNameIdentityPermission is one of those topics that just seem so attractive on paper. It has caught my attention since the first early days of .net 1.0. The idea that a class can place an identity demand on a method (or on the whole class), so that it can only be called by another assembly that is signed with a particular strong name. It can be done declaratively with attributes or explicitly in code. Early Quick Start samples like "How do I…Control access to my shared component." seemed so powerful, and even worked in .net 1.0 and 1.1. All is good, right?

The problem is that the whole topic just gives the developer a false sense of security around a class or component library that they may be writing. As a class library or component author, you don't always know where this code will eventually be running; maybe it will be used in a custom web app with some locked down minimal security, but maybe it will be running in a Windows Forms app, executing in a process domain with full trust. You just don't know. And if it is going to be used in a full trust environment, your StrongNameIdentityPermission demand assumptions are hosed.

In .Net 2.0, identity demands have no effect if the calling code is executing with full trust. They always just pass. Apparently there was some hoop jumping in 1.x that prevented identity permissions from having an unrestricted permission state and in .Net 2.0 this hoop jumping has been removed and identity permissions can have any permission state. It kind of makes the whole idea of StrongNameIdentityPermission a moot point; well, except for maybe some pretty well defined scenarios.

I was attempting to code some proof of concept work involving identity demand permissions today, in .Net 2.0; using a simple console app as the harness process. For the life of me, I couldn't get the StrongNameIdentityPermission to fail when it should have. After driving myself completely batty, because I knew this was something I've previously done/tested/used in .net 1.x, I finally read the MSDN page on StongNameIdentityPermission a bit closer. And sure enough, right there under a header called "Important" was this little nugget that made it all come clear:

"In the .NET Framework versions 1.0 and 1.1, demands on the identity permissions are effective, even when the calling assembly is fully trusted. That is, although the calling assembly has full trust, a demand for an identity permission fails if the assembly does not meet the demanded criteria. In the .NET Framework version 2.0, demands for identity permissions are ineffective if the calling assembly has full trust. This assures consistency for all permissions, eliminating the treatment of identity permissions as a special case." excerpt from http://msdn2.microsoft.com/en-us/library/system.security.permissions.strongnameidentitypermission.aspx

'copy mdf to bin' and ghost hunting.

I was playing around with a demo app today on a machine with just vb.express, sql.express, and all the current Winfx downloads; namely, to work a bit with the current WCF a.k.a Indigo stuff. I hate it when you want to test the waters in one area and spend hours stuck in something completely unrelated, but that’s just software development for you.

So, the demo app was supposed to be pretty simple. A couple of small business objects that made up the core of the application that are interacted with through a few web forms. The business objects would use a private tier for persistence with some predefined data contracts and service interfaces used to describe the messaging between the business objects and the persistence service; some simple Indigo demo stuff. The real point of the demo was just to demonstrate how the communication between the business objects and the persistence tier could be a) in process, b) classic web services c) remoting d) WCF/Indigo. It just doesn't matter. There are plenty of reasons to pick one or the other based on security, privacy, performance, current knowledge base, comfort, etc. So, besides for giving me an opportunity to play a bit with WCF, the purpose of the demo is just to reinforce old ideas: focus on getting the object modal right, the contracts and interfaces right, and as technologies change (ES, DCOM, Web Services, Remoting, Indigo) it just don't matter.

Here is where we get to the part about "want to test the waters in one area and spend hours stuck in something completely unrelated". When creating the persistence tier, I added a data source, so that I could take advantage of some RAD TableAdapter fun. The persistence tier wouldn't be working with datasets, but if the designer could save me time by creating TableAdapter goo code and procs, etc. it seemed worth it. When adding the datasource to set this up, I was prompted by a question something along the lines of "the database associated with this datasource isn't part of the project/solution would you like to include it." and then some warning that I ignored. Later on, after finishing the demo app and testing it, feeling pretty good about how quick the whole thing went, I was dismayed to find that my data was never really getting persisted in the database. It appeared to when I was debugging the persistence tier, and I would successfully insert new rows, get new identity keys back and the whole nine yards. But, after debugging, I'd look in the database, and there would be no data. Hmm. I tried it again. Same thing. It all had the feel of transactional stuff rolling back, but after debugging a bit further it didn't look like this was the case; especially since in frustration I removed all transactional wrappers!

A few hours later, I realized the root of the problem was my choice of "copy database to my local project" and then ignoring the part about this meaning the mdf would be copied to the bin directory each time. Wow! How could I ignore that? I guess its just that we press "yes", "I accept', "OK", etc so many times a day that most times we ignore the full content. Anyway, I guess the statement "If you copy the data file to your project, it will be copied to the project's output directory each time you run the application. Press F1 for more information." is not something you should click "yes' to without fully understanding the implications! Here is the "F1" link

So, in the end it turned out to be all my own doing, and just behavior by design (although, I haven't yet stopped to figure out how this would ever be desired behavior.) And after a few hours of attempting to troubleshoot what was going on with the TableAdapter.update method, which I must not have fully understand, I finally realized that it had nothing to do with the TableAdapter.update method :-). Never, in my wildest dreams, did I assume that a fresh copy of my database was being made to my bin directory every time the application was recompiled and run! Ah, chalk it up to the fun of software development. While others spend their weekends skiing, hiking, or driving racecars, some of us choose to chase ghosts in only a way that a software developer can really appreciate.

ToUTC Times 2

Reminder to self… when setting a value on a structure that will eventually get xml serialized in .Net 1.x, as in a web service data contract, do not attempt to convert the local date to UTC before sending the message. .Net xml serialization will do this for you, so that the xml on the wire is always in UTC. Likewise, if you own the service on the other side of the wire that deserializes the message, the UTC will be converted to the local time of that server processing the message. If you make the mistake of converting to UTC before the message is serialized you end up with a date in the xml message that now contains both a time component that has already been adjusted for the GMT offset and the offset itself; in other words you end up doubling your offset impact.

I remember reading or hearing that this (datetime serialization) might be handled differently in .Net 2.0, but I just haven’t tried it yet. I think the plan was to do some bookkeeping in the object to know that it already represents UTC.

Andreas is blogging

Andreas is blogging! Stop by and drop him a welcome comment.

Andy and I have worked together for two different employers. He is a sharp guy with a passion for what he does, and I really look forward to reading his future posts. Hey, with a blog title like My Objective Opinion, you really can't go wrong. (I knew the world was in for trouble way back when I first saw that David West book on his desk) :-)

message mapping, from service contract to component interface

The guys over at Thinktecture, namely Ingo and Ralf, have recently shared an interesting email discussion entitled "Interface design in distributed solutions". In the email thread, they discuss some of the similarities and differences between designing interfaces and contracts for services and components. In the end they develop a decision flowchart that can be used for rough generalizations on deciding which type of interface and contract designs to follow (component like patterns versus service like patterns). This is real interesting stuff and I enjoyed seeing the discussion develope the way it did. As Ralf states on his blog: "because hearing contrasting thoughts next to each other sparks your own thoughts in a different way than reading a just an article explaining some subject"

Towards the end of the thread, they discuss the topic of mapping data between the service data contract and the component interface. Basically, what we are getting at here is message to domain modal mapping, or in a lot of cases message to object impedance.

Ralf and Ingo discuss 3 solutions for dealing with this, which correlate roughly to:

1) The service's data contract class implements component contract data interface

2) Use some sort of reflection based framework to perform the mapping (i.e. the service's contract class looks a lot like the component contract interface and so we let reflection handle the mapping)

3) Explicitly define the mapping

Seldom in the real world is the ratio of this mapping relationship forever 1/1. It may start out as 1. And if you are the same person, team, company building components on one side of a service, the service, and the components on the other side of the service, these "component interface to service contract" and "service contract to component interface" mapping ratios may be forced to 1. In which case it's very tempting to go down one of the two easier streets that are numbered choice 1 and 2. However, I generally look at these two options as falling into that camp of slippery slope stuff; similar to the messy ORM discussions that always rant back and forth in the object to relational mapping world.

I generally lean towards explicit mapping. Do it, get it over with and move on. I believe this is a similar mindset to what Udi is getting at when he says "In the end, the only real thing left is to map messages to service layer calls…" Additionally, after doing some good size mappings between service data contract and component interface myself, I can appreciate Buddhike's follow-up on desiring for this type of mapping to be a toolkit code generator thing; and, as long as that automation is "code generator" automation in an attempt to accomplish choice 3 then I'm good with that too. You can utilize reflection in tools to help generate this code at development time if you like; especially at the beginning of the process. But, I do think the explicit mapping is important (regardless if by hand or with code generator help) and I don't think the automation of the mapping is a runtime thing as I think is expressed in choice 2.

At some point in the lifetime relationship between the service and the component, stuff will need to happen. The component will need to change in ways that a service exposing it can't or shouldn't expose, or the service contract will need to change (extend). When this happens, there is impedance, and the ratio is no longer 1. Perhaps, the necessary extension of the service contract will require the creation of a separate component and thus one service data contract will now use data from two separate components. Perhaps, within the domain that the component belongs, one of the data members within it's contract interface will need to change dimension. Perhaps an integer needs to be a double (I know it sounds crazy, but we all know this stuff happens.) The explicit mapping gives you a point to do the necessary rounding and / or type coercions so the service data contract can remain consistent.

I do understand that Indigo uses an explicit "opt-in" model, and this is cool and has tremendous value and I'm really looking forward to it. However, despite this, I still think that any auto-generated (or attribute based serialization, etc) stuff from the service contract message into service contract class realm, still needs to be considered part of the "service domain" and not the domain in which component belongs. The service process may actually host and give life to some group of components, but this doesn't mean that the service domain encompasses the component domain; it uses the component domain and therefore should be linked to it in an adapter like way. This adapter process is the explicit mappings.

I also realize that in my example above where the service data contract is extended and requires the support of two components we could have the service data contract class implement two separate interfaces. Once again, I just think it is generally dangerous to skip the explicit mapping step from service domain to component domain; as tedious as it may be and as 1:1 trivial as it may seem early on. If time, or resource constraints do force you to skip the explicit mapping step, then keep it in mind down the road before deciding to bastardize the service or the component for the sole sake of the other.