Have you ever wondered if/when a transaction in WCF upgrades to the DTC? There two simple ways to check this:
- Open Performance Monitor and add a new counter. Get the counter Active Transactions from the Distributed Transaction Coordinator section.
- Open Component Services and go to My Computer in COM+. There is a folder for Distributed Transaction Coordinator, through which you can view the DTC statistics.
In both cases, you’ll see the active transactions jump from 0 to 1 when a transaction upgrades to DTC. This happens when you cross a service boundary. If you just use a transaction within the service, WCF will stick to the Lightweight Transaction Manager as long as you stay within you AppDomain or access a single database (SQL Server 2005 and up).
For those of you that attended my sessions in Dallas, here are the demo’s for
If you attended the latter, you’ll remember that I wrecked my prepared demo (note to self: never change configs just before a session). I finally figured out what was wrong. I changed some configuration on the server side and I thought I did the same on the client. Apparently I did not, because when I updated the service reference on the client it worked.
At a session about ASP.NET DynamicData at VSLive in Dallas, one of the attendees asked me about my thoughts of DynamicData becoming a part of ASP.NET MVC. I commented that currently DynamicData is very much based on the current ASP.NET paradigm of pages and controls, whereas ASP.NET MVC is not. ASP.NET MVC presents a new way of thinking to the ASP.NET world and I find it hard to believe that millions of developers will jump on the ASP.NET MVC bandwagon immediately after its release (let’s face it, it hasn’t even been released yet) and leave their old coding styles behind. You need to learn to think differently first. Also, if ASP.NET MVC becomes the primary ASP.NET paradigm, there is a whole lot of code that is still using ASP.NET the way most of us do at the moment. That said, ASP.NET MVC is very interesting.
Ok, so back to the original question. If you look at Scott Guthrie’s post about the ASP.NET MVC Release Candidate, you’ll see that there is scaffolding support on based on the model, instead of table based scaffolding using in ASP.NET DynamicData. The model based scaffolding enables you to create different views of the model in no time.This is very cool, because it provides you with way more control over what is happening than in DynamicData. And because it is based on the model, you’re not tied to database objects, but rather to business objects. How you persist those is up to you.
I still think ASP.NET DynamicData and ASP.NET MVC are going to live side-by-side for quite a while, and that they will use concepts that were created for one or the other. The main reason for this belief is based on my earlier comment: I think ASP.NET MVC and ASP.NET “Classic” will run side-by-side for a loooooong time. I do feel that ASP.NET MVC ultimately provides us with more flexibility and will at some point become the more dominant paradigm.
At VSLive in Dallas last week I promised to follow up with a post about securing an ASP.NET Dynamic Data application. Your first concern is not exposing all the tables, so although it demo’s well, never set ScaffoldAllTables to true. That however, does still not solve how you can provide read-only access to certain users, while providing edit access to others. The most elegant way to do that is at the Data Model level, using a custom security attribute. There’s a great sample on how to do that on the Dynamic Data Samples on Codeplex. The specific sample you want is Secure Dynamic Data.
If you don’t want to spend the time to understand how security at the Data Model works, you can also just use ASP.NET Roles to secure specific parts of your site. Since securing folders/files that way has been around since ASP.NET 1.x, that should be easy enough :). There is a gotcha though: you cannot secure dynamic folders. In other words, a Dynamic Data path /SomeTable/List.aspx is not securable, because SomeTable is not an actual folder. With three simple steps you can get around this.
Step 1: Create a folder corresponding to a specific role, for example “Readers”.
Step 2: Create a web.config in that folder limiting access to the role(s) you want to give access.
Step 3: In globas.asax, route the tables and actions that apply to the specific role to that folder, like this:
Constraints = new RouteValueDictionary(
action = “List|Details”,
table = “EvaluationSubjects|Reports”,
Model = model