Andres Aguiar's Weblog

ASP.NET 2.0 databinding, 'stateful' entities and Atlas

If you read about the data binding support in ASP.NET 2.0, it always says that is designed for the natural stateless nature of the web, which basically means that each time I update something in the page, it's persisted to the database.v

I was concerned about this, because most of the interesting CRUD scenarios in DeKlarit applications are hierarchical DataSets, like an Order, and it is not an option to add an Order Line to the database each time a user adds an Order Line in the web page. I need to have the whole order, validate it, save it in a transaction, etc.

One of my goals in the PDC was to find out if there was a way to build this with the current data sources or not.

The only way to do it is to use ObjectDataSource, and make the Update(<field list>) method that the ObjectDataSource calls, update a DataSet row. This means that for each DataSet, you need to write a class that will be the adapter between the datasource and your class.

This also applies to standard objects. If you have an Order class and you want to add a line, you need to do the same, create an adapter class that loads the data from the datasource to the class.

IMHO this sucks. The good news for DataSet users is that it's possible to write a generic DataSource (let's say a 'DataSetDataSource') that you can bind to any DataSet and make it work the way I want. If you want to do it for objects, it's also possible but you'll need to use reflection to set fields in the instances and probably make some assumptions on the class' structure.

In the 'Ask the experts' session, I asked some PMs in the ASP.NET team about this. Basically the answer was that if I kept the DataSet in the session my apps would not scale, as keeping state in the server does not scale. My reply was that a DataSet was not different than a standard class, so this problem existed anyway. The problem is you need to keep state somewhere (ViewState, session, database). As I also need to track changes, DataSets looked good, but it applies to any 'track change artifact'.

So, I suggested that I could use the ViewState, and the answer I got was that if I keep the DataSet in the ViewState then the changes will be lost. I could not understand why, but I was not in position to debate it. I later tried it, and that's actually not true. Keeping the DataSet in the ViewState makes the ViewState big, but it does keep the changes and the original data correctly.

To make things worse, in the Atlas.NET presentation they showed that they needed to build a 'dataset like' class with JavaScript to track changes in the client. To talk to the server, you need a class that implements methods like 'Update'/'Insert'/'Delete', etc, and the Atlas infrastructure will call it. They won't call each method from the client, they will stream all the changes in one roundtrip and call the methods in the server. First question, why don't serialize it to a DataSet?? Second, how will they manage transactions, validations, etc?

As a general impression, it looked to me that the ASP.NET team did not understand the real-world issues we face when building database-based applications, and that they also don't know how the DataSet works and why is it there.

ASP.NET 2.0 databinding is great for read-only data, but is lacking when you want to update it.

Atlas ... :(

I did attend to all Atlas-related sessions. I was kind of disappointed, not because of its power, but because of its complexity.

They are basically building a new scripting language in XML and a set of OO libraries in JavaScript, so it's like a whole platform. I'm not Javascript expert, but the code required to achieve simple tasks was not trivial and usually it was a lot of code.

I hope that when the platform matures it gets easier to use, and that it gets good design time support in VS.

Objects are 'done'

That's a Don Box's sentence, from PDC03, when asking to himself if objects were dead. He said that they were not dead, they were done, in the sense that we should stop thinking as objects as the technology that will take us to the next step.

Workflow is a wonderful thing. I guess it won't be easy for us .NET developers to realize that we need to change the way we build applications, but the ones who do will be in much better shape than the ones who don't.

Now, with a workflow and a business rules engine in the platform (WWF has both), it looks much clear than making your objects contain just data that flows between services and workflows has an interesting number of advantages over building a domain model.

Let's see if domain model heads realize it.

Linq, DLinq and XML-based Mapping

LinQ is very cool and we all agree with that.

DLinQ seems oriented towards being a simple way to access data that covers most of the simple cases. I think it will add a lot of value to the .NET platform. Now, if you are looking for a 'real' O/R mapping it seems that you'll need to look somewhere else.

But that 'somewhere else' could be inside the .NET platform too. It looks that nobody realized that in DAT200, Pablo Castro from the ADO.NET team showed an .XML file with mappings, and used LINQ over it. The interesting part was that he was not using DLinQ but another mapping technology.

So, if you are looking for an XML-based mapping technology in the .NET platform,  there's still a chance. However, I doubt that MS will include two O/R mappers in the framework, so it will be interesting to see how this story ends.

Server-side Excel

I made one of the Hands on Lab on server-side Excel.

Basically, using webservices you can create an instance of an Excel document in the server, set a cell with a specific value, and get the value of another one (you can do more than this, but that's the idea). So, if you want your end users to modify the way some calculations are made, they just need to update an Excel document, and your application will use it. You can see it as a business rules engine, even if it's not exactly the same.

If it scales, it will rock. I'm not sure if in the server it's calling COM code or pure managed code, but knowing the reputation of the Office team, I'd bet that they are calling COM code.

They also have a Excel->HTML/Javascript renderer. You can see an Excel document in the browser, with a UI similar to the real Excel. It looks that you cannot edit cells (at least it wasn't mentioned in the Lab), but you can specify values for specific named ranges. If you have a list with filters, you can also apply the filters in the html page. I'm not sure if it pivots or does graphics.

'Now is a great time to be a developer'

"And so it starts, as Bill Gates and Jim Allchin kick off PDC05 with the opening keynotes. For fourteen years, the PDC has been a meeting place for the developer community. It is where developers passionate about software can connect with their peers and the developers at Microsoft. Today’s keynotes highlight the fact that now is a great time to be a developer – it is time to take the next step up in user experience, connectivity and personal computing. "

I think I've been hearing this since I began attending MS events ;). I know it's still a great time to be a developer, but please be more creative!

DAT200 - Future Directions for Data-Driven Applications - See you there!

Someone in the ADO.NET team hinted me that tomorrow in DAT200 they will show some stuff they've been working that is very interesting, and that will be made public in that session.

If you are into O/R mapping or thinking on better ways of working with relational data you need to be there. It's not about Language Integrated Query ;).

PDC Photos

Check the PDC05 tagged photos in Flickr here. There are 47 at this time.

You can subscribe to the RSS (just 10 pics).

Warming up for the PDC - What to do Tuesday at 6PM?

It looks that it's going to be a fun week!

Tuesday night there's a Mono meeting at 6PM. At the same time, it's the PDC Undeground RD event, so I'll have to choose. The Mono one looks more interesting, as they'll showcase the 'Google Summer of Code' bits:

Additionally, the Mono T-shirt looks very cool!