Use of MVC pattern in ASP.NET Web Appications

Something that I have come across on all ASP.NET projects I have seen is the lack of use of the MVC pattern. Rather the code-behind for each page acts as a kind of front controller. But in applications with complicated flows I recommend against putting controller logic in the code-behind of each page, since it makes it difficult to see how the control flows through the application.

If you want to use MVC style of programming there are some alternatives out there:

- The "User Interface Process Application Block" provided by Microsoft.
- The .NET version of het Maverick MVC framework

I also think that the new Windows Workflow Foundation can be used to implement MVC solutions.

I think that many .NET developers would see the benefits of MVC style programming by checking out one of the many frameworks available for java, even though most of them are not without their problems.

Software Factories

I recently watched an interview on theserverside.net (A great site for .NET developers, if you are into java, you should check out its siebling .com) about software factories. A sloppy summary below:

- Assumes that there is a need to industrialize software development through reuse of patterns and concepts related to an industry or an area of functionality.

- Essentially a software factory is an advanced IDE that incorporates functionality to create an own modelling language that can be used to generate code, together with patterns and guiding principles for implementation.

- Example from www.softwarefactories.com: "For example, we might set up a Software Factory for thin client Customer Relationship Management (CRM) applications using the .NET framework, C#, the Microsoft Business Framework, Microsoft SQL Server and the Microsoft Host Integration Server. Equipped with this factory, we could rapidly punch out an endless variety of CRM applications, each containing unique features based on the unique requirements of specific customers".

My head has allready started spinning with ideas on how you could grow a business based on the appliance of software factories, such as:

- Have a consultancy geared towards one or more fields that utilize software factories to build high quality applications quickly.

- Use software factories to achieve mass customization in a product company.

Transaction alternatives in an enterprise architecture

If you are implementing transactions in an .NET 1.x enterprise application you basically have two different alternatives, (1) to use manual transactions or (2) to use automatic DTC based transactions.

Manual transactions are not very attractive if you are not certain of the transactional contexts an object can be used within. This means that the code for handling the transactions is not likely to be pretty.

Automatic transactions are compelling, but requires the use of the COM+ programming model with all its complexities.

I usually find it best to use manual transaction while awaiting .NET 2.0. I this new version of .NET, there is support for automatic transactions without the requirement of COM+. If you are going to implement manual transactions in .NET 1.x, there is a framework that can make your code more structured:

http://www.devx.com/dotnet/Article/28937

Tracking Message bodies in BizTalk 2004

One thing that I’ve found rather confusing when reading the BizTak documentation is how and when BizTalk message bodies marked for tracking are stored. I’m not an expert at BizTalk yet, so this is just my interpretation of the workings = )

In BizTalk 2002, a distinction was made between tracking individual fields and logging whole messages. In BizTalk 2004, tracking is used for both of these actions.

The BizTalk native XML Message bodies are automatically stored in the MessageBox for messages with the service instance status not set to completed. The tracking information
regarding the message is saved in the Tracking database. The documentation states that tracking data is cached in the MessageBox and moved to the Tracking database in intervals, which means some tracking data could be lost in the events of a failure.

When a message has received the service instance status “completed”, the message body is not guaranteed to be available anymore. If you have enabled a certain message for tracking, the native and the BizTalk internal XML representation of the message is saved in the MessageBox. This tracking can be enabled in two ways. One alternative is through configuring the port in the BizTalk Explorer. Alternatively, you could enable tracking for a whole pipeline using HAT. To get access to the message body you access HAT, but note that the message is actually stored in the MessageBox.

Eventually, the message will be purged from the MessageBox through automatically scheduled SQL jobs run by the SQL Server Agent Service. If you want to have guaranteed access to a message body you must configure your solution to archive the messages and then restore them on the Tracking Database. There are some sample scripts in the BizTalk 2004 SDK that accomplishes this:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdk/htm/ebiz_sdk_samples_qico.asp

So if you’d want to have the message bodies automatically archived, I suppose you could modify the SQL job so that it archives them before the MessageBox is purged.