Yesterday I thought I’d learn about the LinqDataSource in ASP.Net 3.5, and got an interesting surprise.

The new LinqDataSource can also be used with a LINQ-to-SQL model to perform updates. You simply add the DataSource to your page, set the table name, and set EnableUpdate to true. Then, using a standard DataControl, you can make updates to your data entities.

The question is, how does this work? It appears to be a bit magical.

The Magic of LINQ

In a previous post, I mentioned that LINQ-to-SQL updates can be done in two ways: either you make a call to retrieve a row, then update it, or you provide known values for all fields and try to update using optimistic concurrency.

If the LinqDataSource used the first technique, the performance might be bad. Plus, it would have to only update those fields that had been updated by the DataControl, and ignore the rest. That wouldn’t make sense, so I correctly supposed that was not what was happening.

It makes more sense that the LinqDataSource would use the values input by the user to make the changes. It could use optimistic concurrency to compare all the entered values.

The problem is, I don’t always display all fields from a particular row on the form, so how would the LinqDataSource know what the missing fields were. Remember, all the fields involved in the update are required for the optimistic concurrency to work. That is usually all the fields in a row, and they aren’t usually all displayed.

So, have a guess. Where does the LinqDataSource store it’s values?

Let’s think now. Where would be the easiest place to keep it? To keep it really simple, I’ll let you ignore all other aspects of building an application, like security or performance.

Yep, you guessed it – ViewState.

The ViewState actually contains all values for all the fields in a LINQ-to-SQL entity by default. Those values are sent to the client, even if the user isn’t supposed to be able to see them.

Aaaarrgghhhh!

Now, let’s not get overexcited. The ViewState is encoded, so it’s not easy to just go and change it. But it’s not impossible. In general, I don’t think it’s such a great idea to have all data sent to a client by default. Someone is going to overlook something one day, and there’ll be a costly mistake.

And what if you display a large grid using the LinqDataSource. Well, you aren’t just getting the ViewState from the grid sent back and forth with your page, but the LinqDataSource is going to store all your data retrieved in the ViewState too.

Bummer!

Great control. Large overhead.

Kicking out the ViewState

The good news is that the ASP.Net team realized that this was a problem and did something about it.

If you look carefully, you will notice that the LinqDataSource has a property StoreOriginalValuesInViewState. By default (sigh) that property is set to true. If you set it to false, the control won’t work any more. Simple as that.

Here’s what the official documentation has to say about that:

If you set the StoreOriginalValuesInViewState property to false, the original values are not persisted in view state for the data-bound control. In that case, LINQ to SQL cannot verify the integrity of the data. LINQ to SQL will throw an exception that indicates a data conflict even if the data in the data source has not actually changed.

That’s in the remarks section of the LinqDataSource.StoreOriginalValuesInViewState property documentation.

Funnily enough, the same section states the problem with stuffing data into the ViewState:

Storing the original values in view state can cause the page size to become unnecessarily large and can expose sensitive data to a malicious user.

Now, I don’t know about you, but that looks like a pretty serious warning to me. Why isn’t it in a more obvious place, like as a comment that pops in up Intellisense whenever you use a LinqDataSource?

Check the UpdateCheck

So how do you handle it? How can you use the LinqDataSource?

The answer lies in the generation of the LINQ-to-SQL model which you generate. Each entity field has a Column attribute which allows you to specify if it is used for checking during an optimistic concurrency field comparison.

For example, you could create a Model with the following Property:

[Column(Storage="_AddressID", UpdateCheck=UpdateCheck.Never, ...
public int AddressID
...

Notice the UpdateCheck.Never value. That means that the field will not be used in the optimistic concurrency check.

The documentation helps a little again:

By default, when update and delete operations have been enabled, the LinqDataSource control stores the original values for all the records in view state. The LinqDataSource control stores values for all primary keys and all properties not marked with UpdateCheck.Never in the Column attribute. You set the UpdateCheck property of the Column attribute in the O/R Designer.

Admittedly, I haven’t yet tried that, so I don’t really know how if you can change that setting for a field without changing generated code, which would be a big no-no. I’ll just have to get back to you on that.

Stamp In, Please

However, there is a shortcut trick.

Basically, if you add a field of type timestamp to your record, only that field will be used for the concurrency check, and only that field’s data will be stored in the ViewState.

If the underlying data source contains a timestamp field that is automatically updated during an update, you can store only that value in view state. In that case, the timestamp property in the entity class is set to IsVersion=true and all the properties are set to UpdateCheck.Never. Because a timestamp field is automatically updated by the database every time that data in that record changes, LINQ to SQL determines from that value if data has changed. This helps reduce the size of view state, and no sensitive data is exposed. LINQ to SQL will check for data consistency by comparing the timestamp value in view state with the timestamp value in the database.

The documentation is great, if you know where to find it.

Conclusion

So, the answer is, if you use the LinqDataSource to throw a quick application together, make sure you use a timestamp field in your table. Call it UpdatedOn, or something. It will make the use of the LinqDataSource a lot easier, if only because you’ll sleep better not worrying about it.

I was recently asked to do some research and give a presentation about using Visual Studio Team System 2008. I thought I’d experiment with Slideshare.net and post it here.

The presentation was for a large corporation, and will possibly not come across as being very useful for an online presentation. I have been working on it for a while though, and I think it’s worth publishing, if only as an introduction.

I’ve used competitive products to Team System for a long time, mainly open source:

• SubVersion for source version control
• CruiseControl.Net as a build server
• NAnt for build scripts
• MbUnit for testing
• NCover for seeing my testing code coverage
• VersionOne for project planning, task management, tracking and reporting
• BugTracker for bug tracking
• A Wiki for project documentation and guidelines

I wasn’t all-too impressed with the standard of Visual Studio Team Suite 2005, but I am a little bit happier with the 2008 version. It took a while to get it installed so that I could test it, and there were lots of seemingly undocumented points which hindered my progress, but once I’d got it up-and-running, I didn’t find it that bad. (I did have to install it on  virtual machine, and run it on my laptop.)

I think the best thing about Team System is that all the things I need to do are now integrated into one place. I didn’t have to go make changes to a dozen XML files in order to get a build server working. I didn’t have to install a Wiki for the project documentation. Using Team System would also avoid resistance to using the products, as I’ve faced before trying to get other team members to use such tools. Everything would just be there, out-of-the-box, and no one would argue about using them.

What I didn’t like about Team System are some of the subtle details which don’t work as they should do. I did a basic test of multiple check-outs, using the new features, but it didn’t work. The Unit Tests that I generated were confusing and were buggy.

The biggest problem though is the price. It’s darn expensive. I wouldn’t be able to afford Team System if I was just a small development shop. However, for a large corporation, it really could make sense.

I actually wonder if there’s room for a better competitor (Rational is possibly the only serious contender, and I find their software pretty naff). It actually wouldn’t to be too hard for some Python hackers somewhere.

DotNetRocks, the internet talkshow for .Net developers, has a great show about development changes over the past 20 years. Carl Franklin interviews Kathleen Dollard, who has put a list of changes together, and is publishing them online.

If you want to know where you currently stand in your software development, you want to listen to this show. You might even want to take notes.

If you are recruiting developers, you also should listen to this show. You could use very effectively it to find out what kind of people you are interviewing.

The first 10 of 60 items on Kathleen’s list of changes are:

1. Parallel entities
2. N-Tier
3. Sheer magnitude
4. Application code generation
5. SOA (Service Oriented Architecture)
6. Semantics and canonical messages
7. Workflow
8. Rules engines
9. Aspect oriented programming
10. Impact of libraries

Every software developer or architect should know at least a little about each item on this list. If you don’t, maybe you could use this to pull your career up a level.

I’m often asked to produce design documents for new applications. I can’t do this without discussing the advantages and disadvantages to each part of the design. A great way to do this is to focus on the desired qualities of the system you’re trying to build. Define the qualities you are trying to achieve, and design each part of the system to match those qualities as best as possible.

It helps to have a list of things to consider. Here’s a list of some of the qualities you need to address for a .typical Net application:

Development-Time Qualities

• Modifiability – (Often called “flexibility“, and especially important for agile development.) How easily can the software be modified to additional requirements and changes? Can changes be localized to as little code as possible? Do public interfaces have to change? How are the parts of the application dependent on one another? Are the most-likely-to-change areas of the application depended upon to be stable? To what extent are concerns separated?
• Reusability – Can units of the application be reused elsewhere? Does the code fit the “DRY” principle (Don’t Repeat Yourself)? Does the system make good use of existing standards? Reusing code from other frameworks and systems can help keep testing and maintenance down, but reduce modifiability.
• Portability – Could the system be easily ported to other platforms? This is often not an issue for most enterprise applications, as business requirements typically change more frequently than the technical platforms, and the .Net framework takes care of most of the issues. For a web application, portability could also include browser compatibility. What happens if the users suddenly receive an upgrade to their browsers?
• Testability – How easy is it to prove that the application functions correctly, and that the various parts of the application do what they are supposed to do in isolation of one another? Can the application be tested automatically? Can the application eventually be tested easily end-to-end as part of an integration test? Can the application be load-tested?
• Buildability – Can the application be built on systems other than those in the development environment? How often can it be built? The more often it can be built, the better. What tools can be used to do the builds? Can they implement continuous integration by building at every check-in? Which third-party controls or components are used? What part do licenses for third-party products play in the ability to build centrally?
• Maintainability – How easy is it to understand the software for people other than the original developers? How easy is it to correct defects? Is the system documented enough to make it understandable?
• Debugability – How easy is it to find out where and why there is an error in the system? How easy is it to find what is going wrong in a live, productive system?
• Extensibility – How easy is it to extend the functionality of the system beyond its original specification?

Runtime Qualities

• Functionality – How well does the software help the users to do their work? Are there missing features which make the software useless? Does the software provide end-to-end support for a particular process?
• Usability – How easy is it for users to understand and learn to use the software?  Is the interface intuitive? Is there a supportive help system? Does the user interface match the users’ needs? Are basic usability standards and conventions adhered to?
• Performance – Does the system perform fast enough? How does it perform when multiple users are active? Where are the bottlenecks and latency in the system?
• Concurrency – Is it possible for more than one user to use the system at a time? What is the performance impact of multiple sessions? Is state shared across the application, making the system unreliable?
• Security – Does the system prevent unauthorized access or misuse? What happens if access is wrongly denied to a user? How easy can security be administrated? Does the STRIDE threat model show up any weaknesses? What is the potential outcome of a successful attack? 
• Integrity – This can be related to security, but it also refers to the data integrity of the system. Is the data always kept in a consistent state, or is it sometimes possible to infer different states of the system because of inconsistencies in the system? Do transactions pass the ACID test?
• Reliability – Can the users rely on the software? Will it always perform correctly? Is it still usable at peak usage periods?
• Availability – How often and for how long is the system available for use? How do upgrades affect its availability? Is the system meant to be used across time-zones?
• Scalability – How does the software cope with adding more users over time? Can the system cope with an increase in the volume of data? What happens if the users start to use the system more often? Must the software scale up or can it scale out?
• Deployability – How easy is it to deploy the initial release of the software? How easy is it to release future releases? Does software need to be replaced, or just patched? How does the deployment affect scalability?
• Ugradability – Can a new version be deployed without stopping the normal operation of the system? What must be changed or upgraded when a new version is released? What third-party software may be upgraded which would affect the software?
• Correctness – Does the software do exactly what was specified?
• Conceptual Integrity – How balanced, simple, elegant, and practical is the whole system? Is there a clear vision as to what the software should do? Is the design consistent?
• User Responsiveness – Related to performance and usability; how does the user perceive the application to be responding? Does the system stop responding for long periods of time, especially when retrieving data? Does the latency of parts of the system lead to decreased usability? Does the software use multiple threads to improve responsiveness?
• Interoperability – How easily can the system be used with other systems?
• Robustness – How does the system react to abnormal conditions? Does it crash, or recover gracefully? Do error messages baffle users and decrease usability?

Priorities

Software qualities must always be balanced against one another. There’s no point in having performance good enough for MySpace.com if it’s not needed, for example, especially if it makes maintenance harder. Each quality has a particular importance for the system being developed.

In general the highest priority qualities are:

• Maintainability
• Correctness
• Reliability

Also important for .Net Object-Oriented design are:

• Reusability
• Extensibility

Most of what I focus on in my day-to-day work is focused on good maintainability and modifiability. Changes come along all the time, and the people paying for the software want them done fast. The faster you can adapt to their needs, the more they trust you, and the better your business relationship.