January 2004 - Posts

Can't unload assemblies
30 January 04 06:09 PM | despos | 2 comment(s)

Just want to publicly thank Roy Osherove for his article Search Dynamically for Plug-Ins on  ASP.NET DevCenter.

I wrote an article about WinForms plugins way back and I'm presenting about it at next DevConnections show in Orlando. I normally use a static XML file not even a config file to avoid bringing in a custom configuration handler. I've extended it to use a file monitor on the XML file so that changes to the file are detected in real time, but I never thought to check assemblies dynamically to make the discovery dynamic.

And more importantly, I've never considered that AppDomain is the smallest unit of code you can unload from a .NET application. It's funny when you know things but can't make connections, isn't it?

Thanks, Roy. 

Hard choice but choice
30 January 04 05:53 PM | despos | 9 comment(s)

Kathleen says something important in her post about ObjectSpaces: "For almost all of us mapping is an issue resolvable at design time. Thus I think code generation is a much better model for most of us."

Runtime egg or design-time chicken?  

 

ObjectSpaces Showdown...
30 January 04 05:51 PM | despos | 2 comment(s)

I think that really interesting statements and comments have been posted in the various threads about ObjectSpaces. A monumental THANK YOU to you all.

Kathleen Dollard said "You'll accept a 30% or greater perf hit for simplicity in programming? Sorry, but I think that's nuts." I've been brought up thinking that scaling hardware up fixes many things... <g>

Paul Wilson pointed out that "Actually, the 30% extra overhead comment that's been circulating was widely misunderstood.  They were stating what they think ObjectSpaces can be compared to DataReaders, not DataSets. When they clarified this it was clear that they don't think there should be much, if any, overhead when comparing to DataSets."

It's interesting to see how to chase my thoughts I was completely losing the perspective of a thing like ObjectSpaces.

Here's (what I believe is) a (to date) summary of the ObjectSpaces stuff.

• It is not that you create an object model for the sake of ObjectSpaces; you use ObjectSpaces because you have an object model that you want to persist.
• You must have a strong business layer to use ObjectSpaces; it is not a matter of having a large or complex application
• If you need maximum speed and flexibility use ADO.NET; if you have a strong business logic layer use ObjectSpaces; if you're writing a data driven application use perhaps the XML/ADO.NET API

 

Essence of Pro ASP.NET
30 January 04 05:21 PM | despos | 3 comment(s)

What an Amazon reviewer wrote about my Programming ASP.NET book:

Don't get this book if you are not willing to invest the time or do not want to really understand ASP.NET.

Not sure whether this is a good or bad statement about a book that wants to be bestseller... However, I think that the essence of the book is all in these words. Thank you Patrick (if you read this...)

First MTS, Next ObjectSpaces
27 January 04 10:19 AM | despos | 7 comment(s)

Let me say it up front--there's no direct and logical connection between MTS and ObjectSpaces. However, the more I think about ObjectSpaces (and the more comments you post--BTW, thanks a lot and keep them coming), the more I feel that a common pattern exists out of the two distinct and different technologies.

It was around 1997 when Microsoft announced MTS, aka Microsoft Transaction Server. Here's a quote from an old MSJ issue, whom author was the excellent David Chappell. 

MTS isn't magic, but it does let you write simple, COM-based servers that are still powerful and scalable. MTS provides a range of services to those apps, including thread management, efficient object activation policies, and support for transactions.

The MTS programming style was then summarized in a few ad hoc programming rules. The primary and perhaps unique goal of MTS was helping the developers of multiuser enterprise server applications to focus on their own business logic and problem domain instead of spending time and effort solving interesting but off-topic problems like thread management, security authorization, distributed transactions.

Like many other things in this our imperfect world, MTS was probably no ideal for just everyone. For sure, instead, it helped many people to build better applications, faster. (Hey, sounds like the new Wintellect's payoff.) 

Knowing nuts and guts of your app, you could probably come up with a layer of code not as generic as MTS, but more apt to your particular context, and then (maybe) more performant. You need to invest time for this, but if you started this effort long before the advent of MTS you were more than halfway. In my experience, I've seen multi-tier apps successfully built with MTS, and multi-tier apps built with full success without MTS. I can't remember to have seen apps that had to drop MTS support to work better.

I could have been short-sighted, though. Don't take this statement as absolute truth. Did you see an app that MTS slowed down?

So what's up with ObjectSpaces and what's the common pattern I think it shares with MTS?

ObjectSpaces is being built to help people persisting objects to databases. From your comments, the bottom line seems to be that nobody doubts that an OR/M tool is needed. You seem to doubt that ObjectSpaces is the right one. Two good objections I caught here and there are:

• The efficiency of the tracking system
• The quality of the SQL code being used under the hood

The tracking system is being revised and I expect custom classes be required to implement special interfaces in the near future.

ObjectSpaces is young. I don't know about you, but I'm working with the PDC bits, that it less (much less) than a public beta...

Goal of ObjectSpaces is adding no more than 30% of overhead. If you think you can do better in the same time it takes to map tables to classes with ObjectSpaces... If this target is hit, I would recommend ObjectSpaces not just for complex and high-scalable apps but especially for medium and small apps. You come up with an easy to use/maintain (and fast to write) data tier in a snap.

Like MTS, I buy the statement that ObjectSpaces is not great for everybody. But it would probably make life easier for more people than I myself thought two weeks ago.

PS: I believe you can replace the word ObjectSpaces with the name of any other good managed OR/M framework. However, having source code (and a good team of experts) is key in this case.

 

 

ORM
21 January 04 03:49 PM | despos | 17 comment(s)

Is there anybody using ORM.NET or other ORM tools right now to build .NET apps? If yes, how do you feel about it? Did you choose it over ADO.NET?

ObjectSpaces 2
21 January 04 03:20 PM | despos | 8 comment(s)

I've been a little bit too simplistic in the previous post, as Frans pointed out in his comment :-)

When you use your own objects with ObjectSpaces, physical serialization/deserialization a la .NET formatters is not taking place. What I meant, is a "logical" form of serialization in which data flows in and out of your classes.

Of course, the developer needs to know a lot about the entities involved and their relationships. A developer doesn't necessarily need to know about the names of the tables, the columns, and most physical constraints. Personally, I believe that the beauty of tools like ObjectSpaces lies just here.

I agree that the more you know about the data structure, the better you can write the code. But when dozens of developers are involved in a large project with tons of tables, are you sure you can afford this? Isn't it better using a programming paradigm that shields a large group of developers from the nitty-gritty SQL details?

I don't know how ObjectSpaces tracks changes to objects, and I'm not even sure that the current is the final solution. However, personally I would have used a common base class with a sort of base Modified property to set and reset programmatically. Perhaps a bit more complex task for developers, but hopefully a better average performance.

Comments?

 

 

ObjectSpaces
21 January 04 01:04 PM | despos | 5 comment(s)

Like many of you, I first heard of ObjectSpaces around the PDC 2001 timeframe. I've got the bits and installed on a completely insulated machine. I've never run even the simplest demo. Several months later, I've been told (rumors, sort of) that ObjectSpaces was completely redesigned and reimplemented. ObjectSpaces is not part of Whidbey and glimpses of it have been illustrated at the last PDC.

I confess that the first description I've heard of it (2001) left a sense of "unfinished work". Not that the work is finished today, but at least what ObjectSpaces is and how it works is clear.

ObjectSpaces is a managed ORM--object/relational mapping tool. It allows you to read/write database information using custom classes as the "currency". Your application passes objects and gets objects in and out of the data source. Any serialization/deserialization process is taken care of and application developers don't need to know about the data model and SQL details.

.NET practices about building a data access layer suggest you stick to ADO.NET objects and streams for better performance. ObjectSpaces seems to take the reverse approach. Where's the break-even point between complexity and performance? What's the real cost of this code?

For Each c As Customer in reader

 ' ...

Next

My feeling is that ORM tools are incredibly useful in incredibly complex applications. How complex are yours?

Thoughts?

 

Accessible DataGrid Header
14 January 04 05:50 PM | despos | 6 comment(s)

An easy way to get a DataGrid control to display a <TH> row? As you probably know, by default the header row shows up using <TD> elements. However, <TH> elements are often required for accessibility purposes. As far as I know, in Whidbey the GridView control--the DataGrid successor--will have an ad hoc property that, if  set, enables the control to generate a <TH> header.  

How to get the same for ASP.NET 1.x? As Scott Galloway suggested, go here and get this hotfix for ASP.NET 1.1. Or in alternative read on.

I'm afraid you need a super DataGrid class. The following code captures the markup that a certain fully configured DataGrid control would generate.

StringWriter writer = new StringWriter();
HtmlTextWriter buffer = new HtmlTextWriter(writer);
base.Render(buffer);
string gridMarkup = writer.ToString();

The gridMarkup string contains the HTML text for a table. At this point, you parse that text and replaces the header's TD with TH elements. When you're done, you simply output the new string. Where does all thing happen? In the overridden Render method of your super DataGrid control.

protected override void Render(HtmlTextWriter output)  
{

   // Get the default markup

       // TODO

   // Modify the string

      // TODO

   // Write it out

   output.Write(gridMarkup);

}

This code is illustrated (with other purposes) in my January 2004 Cutting Edge column on MSDN Magazine.

ScrollableGrid posted
14 January 04 05:38 PM | despos | 5 comment(s)

Some of you refreshed my poor memory. I promised that the source code of aspnetPRO articles would have been available through the Code Architects Web site. OK, the ScrollableGrid control should be available now.

Go here and and register.