Object Binding with Deborah Kurata

August 2006

Click ARCast: Object Binding with Deborah Kurata to listen to this ARCast.

Are you in a bind? Is your UI code filled with lots of trivial work like moving text back and forth between controls and business objects? In the past, most people thought that data binding was just a clever trick to use for demo applications or quick and dirty projects; but no more, my friend. Now, we have something really cool in .NET 2.0 and it is called object binding. My guest on today's show has written the book on object binding, so listen up as Deborah Kurata sheds light on the depths of object binding.

Ron Jacobs: Yeah, how is it going? I am going to need you to move over there. Yeah, and if you can just tune in and listen to ARCast, that'd be great. Thanks a lot. Yeah, thanks, Mr. Lumberg. Hey, if you haven't seen the movie Office Space, you have no idea what that was all about. Hey, but I am your host, Ron Jacobs, coming to you once again on ARCast, where we are bringing you yet another conversation from VS Live San Francisco, where I am chatting with Deborah Kurata about object binding.

Yeah, you know, data binding has been around for a while. Lot of people are kind of, like, that's cool for a little demo, I don't know if I am ever going to use it, but object binding, now that is something very cool stuff. I want you to think about, what you might do with it, as you listen to Deborah. Let's give it up for Deborah Kurata.

You were the podcast pioneer for my podcasting career; actually, it was this time last year at VS Live when we sat down to record an ill-fated podcast that never made the air, because of a rookie mistake that I myself made.

Deborah Kurata: That's OK. We were just moaning about something anyways.

Ron Jacobs: That's right. As I recall it was something about VB and not supporting VB and patterns and practices.

Deborah Kurata: Enterprise Library.

Ron Jacobs: Yes, that's right. OK.

Deborah Kurata: Yes, and it still only is in C#.

Ron Jacobs: Yeah, but you know what, the composite UI application block, I think has a VB version and the smart client team heard you loud and clear. So, all of the smart client blocks are going to be both. OK, so maybe that puts some pressure on the enterprise library team, who knows.

Being one of the experts here speaking at VS Live, I thought I would talk to you today about some, some interesting work that you have done recently. So, you were telling me about an article that you wrote for Code Magazine. What was that article about?

Deborah Kurata: It was on object binding. I know binding has been something we have been told forever since VB3, if I recall, not to use in real application. You know, it was always something that you did, if you needed a prototype or a something to manage your basic admin duties with but you wouldn't write a real business application and use binding.

Well, now, over many 20 years later, however long it's been, we finally, finally have a binding story that's really good. So, I have been writing a lot about object binding. I am speaking about object binding and really, truly enjoying it, and I am in the process of writing a book.

Ron Jacobs: You know, it's funny that you mentioned the history of binding, because, gosh! It was more than 10 years ago now. I think it was about 12 years ago, when I was living here in this San Francisco area, working on another client-server Windows development tool and our development manager came to me and said, "Our competitors are killing us with these little demos they build, you know, they just come in and the sales guy shows how you can assemble an app in five minutes and, and that is killing us with these things. We got to do something."

So, I went away and then invented this whole data-binding scheme for their tool, and it worked.

You know, you can build the app in five minutes, but it wouldn't be an app that you would build for anything serious, right, and I was amazed though how many people wanted to use it and it was very elegant you know, all wired up everything dynamically at run time, but it was kind of slow, that was its down side, but then in the second version, I made it more, like, just general code generation sort, design time you kind of set up everything and then it just hardwired all the controls to data sources.

Anyway, the second version performed much faster, but still wasn't very useful for real applications, because it wasn't very extensible, which was the downside. Once I fixed the performance, then it wasn't extensible at all. So, but I have heard the same thing, you know, people go, "Oh! Data binding come on! Give me a break." That's something that you only see Microsoft people doing demos with that. But, but now, with .NET 2.0, it's gotten pretty cool, hasn't it?

Deborah Kurata: Object Binding in particular, Object Binding is a type of data binding you can still bind to databases and doing a you know, two-tier kind of application but the coolest part and the part that I am excited about is the object binding portion or the object binding kind of data binding.

With object binding, unlike normal data binding you are actually binding to your code in your business objects and not binding to some Microsoft generated code or binding directly to database tables and fields. So, that's very exciting, because it's basically unlimited in its extensibility, because you are binding to your own codes. So, whatever you would write is whatever binds you.

So that it is incredibly exciting for me. The book that I am writing is called Doing Objects in Visual Basic 2005 and it covers all of the basic techniques for not only doing object-oriented design and development, but then also implementing all of the object binding, and it's very interesting to see how much that you can do with it.

I am using all of your own business logic and all of your own validation and everything, all in your business component and not having to have a lot of code in your user interface.

Ron Jacobs: Yeah, because that was a big problem with binding to, like, a data set or something, right, you have to manage its extensibility then try to do validation and what not. That was hard thing to do.

Deborah Kurata: Lots of events all over UI and so wasn't encapsulating all of that in your business objects where, where basically they belong.

Ron Jacobs: Well, you know, I've always been an object kind of guy. I didn't, I don't know data sets are nice, but they kind of make my skin crawl, when I see just a big hunk of unstructured data and, you know, we just gonna link to it and I just like to have an object, if I am working with the customer table I want to have a customer object to work with.

Deborah Kurata: And I still, I am using data tables in my code to populate my business objects with. So, I am still making use of data tables, data sets, or you can use data readers to populate your controls, which is what Rocky Lhotka does in his [umm] object binding.

So, you have again lots of options there, because you are controlling, how your business object works, so you can have your business object caller data access component, like the data access component that's provided by the enterprise library and actually have it return you a data set or a data table, that you then populate your objects with. So, you create a factory method of some type that builds your object and then it binds it to the UI using the object binding techniques. So, it's really, really nice.

Ron Jacobs: Yeah, you know, so you are writing a book you said. Yeah, so, you know what, I was thinking about there has been a lot of news lately about these Oprah controversies with that Million Little Pieces book and the Oprah, but you know what I found, Oprah has a book club, I should have a book club, I should have, like, Ron's book club. So, like, I could recommend good books. You know, people are always asking me, What's a good book and I go, I don't know. But, you know, it would be a good idea, right?

Deborah Kurata: That is a very good idea.

Ron Jacobs: I'm gonna do it. And maybe when you get your book ready, you send me a draft. I will read it and if I think it's good, I am gonna put it in a book club.

Deborah Kurata: OK. I have only three chapters left to go.

Ron Jacobs: Alright, you heard here on ARCast that I am committing to the book club. So, let's see, well, I totally lost track where we were. OK, we were talking about data binding and... and object binding and what-not. So, when you were deciding to research this topic, was that just kind of fell out of your, I am going to write a book about object, some have to do with object binding and better go research it is, and that's how you decided to do this?

Deborah Kurata: No, I'm, I was involved with Microsoft in terms of the really alphas and betas, so I got to see very early on what they were doing with their binding, both DataAdapter, a TableAdapter binding and also all of their object binding.

So, I got very excited about all of that. With the book, I just had to decide how much of it I wanted to cover, how in depth that I wanted to be, but then I wanted to cover every possible choice or selected choice.

So, the research that went into the book was more with regard to what in my opinion is the best path for creating really good object oriented applications, using an N-layered approach. You know, separating your business logic from user-interface code from your data-access piece, and that's really what the book is focused on.

So, I opted not to cover, you know, doing data binding to the database. I opted not to cover TableAdapters or any of that, because I don't think that is really what best practice is yet.

So, I opted to go what within my experience with doing several .NET 2.0 projects is with the object binding and that's what I covered. There are also a lot of complexities that you need to deal with if you going to fully implement all the features of object binding.

For example, if you set up your ErrorProvider control correctly, the object binding will automatically put your ErrorProvider control next to whichever controls have error and then with regards to validation.

Ron Jacobs: Oh! Wait a minute, that's OK. Let me back up for a second, because sometimes people don't know what these things are. So, an ErrorProvider is what?

Deborah Kurata: That little red dot with the exclamation point. In that you can have, I mean, it was available on the first versions of .NET, where you could say, the MyLastName property required and user didn't put it in, so I am going to put this little icon next to the LastName.

The user moves the cursor over it and it presents a tool tip that says, you know, LastName is required. So, it provides you field level validation error messages, and with 2002 and 2003 you could put the control on the form and manually write the code to tell it, you know, what text to put in it and what control will be next to and all that kind of stuff.

Ron Jacobs: OK.

Deborah Kurata: With object binding it will handle all of that automatically.

Ron Jacobs: So, they have come up with a way where in my object I can validate inside. Hey! You didn't put LastName, and set something on my object and then the UI will automatically ErrorProvider will show up next to the LastName field with the nice little red thing.

Deborah Kurata: Exactly, that's exactly correct, and there's two easy ways or there's two ways to do it. One that's really easy, all I have to do is throw an exception, so if any of your property throws an exception it will automatically pop the error icon next to that with whatever exception text you have, but that's not very elegant. So, they also have an interface that you can implement.

If you implement that interface then it provides a richer experience with regard to managing your errors and so I cover all of that in a book article that I wrote for Code Magazine, didn't quite go into that level of detail, but it definitely, you know, with the book you have lot more pages available to cover all of that and that kind of stuff.

Ron Jacobs: So, you know, this is really great, because... Well, my first exposure to the object binding and this is weird you know, because I work at Microsoft people are like, "Don't you, like, play with all of these alphas and betas, and all that," and the answer is, "No," because I just don't have time to do. I have all the other things that I have to do but when we were working on the composite UI application block for patterns and practices, there were quick start samples.

I started looking at each one and try to understand how it works, because we are going to do Web cast about them and one of the first things I do is, you know, try and understand how something works I bring up the UI and then I, you know, start looking at the UI code and see if I can follow it down into the objects layers.

When I look into the UI code that's, like, no connection to anything in the business layer, I see, like, how do they say data get populated. I see it in the forms but I don't see it happening in the code. I don't see that little set CompanyName or our text CompanyName.text = company.text or something like that.

Deborah Kurata: Right. That's a code that's gone.

Ron Jacobs: And it's amazing, because the UI code is actually very, very clean, there's very little there, and it's just dumb, boring code anyway so, like, you are moving device back and forth between object and the properties, so it was very, very cool to see it gone.

Is there anything special I need to do in terms of the way I think about creating objects and that make them friendlier to binding data elements, and we talk about that ErrorProvider, but do I have to implement some IWhackyBindable interface or something like that?

Deborah Kurata: If you just want to do very straightforward binding you don't have to do anything other than have properties. So, in that also, with somewhat different, because it used to be that the big buzz was to have stateless objects and that basically, meant they didn't keep state, which basically meant they didn't have any properties.

So, the industry is kind of moving away from this stateless concept, because of the improvements that used to be for performance reasons or for scalability, or because the way the Web works with being, you know, basically disconnected but all of those problems over the past several years have and been solved other ways.

So, the whole purpose for stateless objects really isn't there any more. So, you can make more stateful objects, meaning objects that have lots of properties.

As long as you have a property on your object, you can use it for binding, so every property is then bound with associated control whether that be a text box or a date control or whatever kind of control you would want or you can do more complex binding and bind your entire object to a grid, so you can see your whole list of customers show up in a grid with… by just doing the binding and then writing the one line of code that associates your DataSource, so it's… it's relatively… relatively easy.

Ron Jacobs: In fact, you can even go through the UI director, like, even if you don't wanna write that one line of code, you can go to the UI to pick up an object binding source, right?

Deborah Kurata: Yeah, but you still do need to write the one line of code that associates the binding source with a particular object instance. So, there is still one line of code, unlike…

Ron Jacobs: Gosh! One line of code, they can't get rid of that!

Deborah Kurata: No, with the data binding, they generate that one line of code if you are binding directly to data, but for object binding they don't really know what your instance is or how you going to get your instance whether you gonna have a create type factory method or how you going to get that instance created. So, that's the one line of code you need is to create whatever instances associated to the data source of the binding source.

Ron Jacobs: Let me inject something here about stateful versus stateless, because actually one of the key reasons why say COM+, for example brought us stateless objects was for transactional integrity, because by using just in time activation with COM+, if you had state that was created in the middle of a transaction we force you to... to dump that state, because we deactivated object before the transactions completed.

The reason is, not so much for performance or scalability or anything else but for transaction integrity, because your object doesn't know the outcome of the transaction. It's deactivated before the transaction outcome is known, which is good for scalability, because we can go on and do something else while the DTC finishes that transaction but if you were able to hold the state across the transactional boundary, you would have to know whether the transaction succeeded or failed, because if the transaction failed the state you are holding might be invalid.

Right, so then you can't keep that around so you got to let it go. So, anyway that was one of the reasons why stateless was sort of forced upon the world in a mould and when we thought that everybody will build distributed app with them hosted on COM+.

I think that's kind of different styles of objects, right, and I think of the kind of objects that I'm gonna use to bind UI controls to something like, as almost like a container for data with a lot of properties and some may be some very lightweight kind of logic around validation and what-not.

Some people like to put the persistence logic right in that, say that's a customer object right, some people like to put it in the customer object maybe even as static methods or whatever, but some people prefer to have a whole 'nother object or maybe a service-like object, right, that's gonna accept the customer and then actually act on it. Do you take any position in those kinds of debates?

Deborah Kurata: Well, one of the things that I really like to do with my classes is really make them focus on their purpose and so for customer class you know, is its sole purpose just to shuffle data around or does it really have another purpose and with maybe something as simple as customer, maybe its only purpose really is to shuffle data around but if you have something like an invoice it has a lot larger of a purpose.

It needs to know how to calculate itself, it needs to know how to do all of the functions that are involved with processing an invoice, it needs to maybe know how to, you know, remove items from inventory when invoice is posted or, you know, all these other business processes that could occur.

So, I think it's really important to define your object model using good object oriented design techniques using, you know [umm], CRC cards or some type of [umm] design tools to help you actually look at the responsibilities of each of your objects and then once you have your basic design done then you can look at the binding scenario, you shouldn't really be defining your business objects for binding necessarily.

Ron Jacobs: Well but there is one key reason why a lot more people have thought about their components more as a simple container and that's service oriented architecture, right, because I have to say use the invoice example.

When you're talking about that, I am thinking, if I would have to be building a system like that, I would probably have a Web service that does invoice processing, right, and it does all that stuff. It might return an object that represents the invoice, but this object's a relatively simple container with property, so, why not. The real work happens back at the service.

Deborah Kurata: Yes, and those you almost can think of as a different purposed class. So, even though you might have your invoice class, you know, back on your server that knows how to do all of the invoice processing, you also might have an invoice entity class whose only purpose in life is to shuffle the data around, because with a server… service-based architecture, most of what you are doing, at least with Visual Studio, is passing around, you know, XML.

So, it really is only data. It's not the logic, you can't really pass, you know, the coding along with the object using service-oriented architecture. So, then you do have the special purposed objects that are your, you know, basically data-transfer objects, kind of your own little DataTables or whatever that, you know, whose only purpose is to maintain that data for transfer to and from your service.

[But] the actual real work then is done [um] in your invoice object that would then be in your service, and that point you are not binding to that, because that's running on a server in New Jersey [laughs], or whatever, it's not where your UI is, and at that point you could, you know, consider actually binding to your entity object that kind of depends upon what your overall architecture is.

A lot of the clients that I am working with that are doing very focused business processes have been installed on end-user systems with all three layers on the user system, so that there isn't a need, really, for a service for the basic part of the business app.

Now, it may call out to a service for a particular process, but the majority of the logic and everything was actually there in the business layer sitting on the end users computer. So, I think that again you need to really look at the purpose of your application, how it will be physically deployed in order to just create these purposed classes that will then basically build the logic of your application.

Ron Jacobs: So, we talked a little bit about some... you know, what kind of object things you need to do, was there anything about object binding that's really surprised you as you kind of looked at it and went like... Wow, what about that?

Deborah Kurata: I think the thing that was most surprising was when I had finished writing my first chapters on, you know, building the UI, building the middle tier component, building the data access component and I looked back and it was amazing how many pictures there were and how little code that was actually required to create basically a full blown application.

I mean, this application does your basic, you know, create, update, delete operations for two different things, products and customers, maintains a list of purchases that customer makes, and I was completely surprised when I was done, as to actually how little code that I had written and how many pictures I had… had, because so much of it is done, you know, with Windows or with, you know, setting options or modifying properties through designers, and not a whole lot of it actually had to be written with code.

Yeah, but using object binding means that there isn't a whole lot of generated code either that you have to carry around. So, I just was kind of surprised at when I was finished how little code I had to have written to actually get my application, pretty much all operational.

Ron Jacobs: Yeah, you know, I can just hear some people out there groaning, "Oh, no! Less code." You know, so code slingers, you know, they... That's what they live for, they want to write lots of code well. Write some important code, because this kind of code that we're replacing was that boring, stupid code that you don't want to write anyway, right?

Deborah Kurata: That's the code that's not in the book. I mean, when it comes to, you know, executing the logic, you know, the more complicated kinds of logic like confirming a customer's credit status or whatever, you know, none of that code's there. So, that's really the code that's left.

So, I guess, the point that I was trying to make is that the foundation of everything that you need to do to get the basics all operational is so simple that you can then focus on, you know, the important code, what is your business logic, how are you going to make that invoice process through everything that it needs to process through and you don't need to focus on how I'm going to display the result to the user that's when you just, you know, drag your business object on to your form and all your controls show up and that part then is easy.

Ron Jacobs: So, that's pretty sweet, I must admit. So, you are saying that actually the Visual Studio designer will allow you to just drop a business objects on the form and it will just, like, generate stuff.

Deborah Kurata: It generates all the controls, yes, so you can drag your business object from your data sources window over on to a form. So, if you add customer for example and you drag it and drop it on to form it would automatically create all of the labels, textboxes, combo boxes, check boxes whatever would be appropriate based on that type of field that you have and it's adjustable. So, you can decide that I want this field to be a radio button, this one to be a check box or whatever.

Ron Jacobs: So, that's really cool, because the thing I wrote, like, 12 years ago, it made everything just a textbox. This is actually smarter than that.

Deborah Kurata: Yeah, it's much smarter than that, plus it gives you complete control. So, if you actually built your own controls… So, say you have your own fancy calendar control that knows how to handle multiformatted dates or whatever. You can actually hook that in, so that when you drag anything of type date over, it would use your control.

So, again, it works very well with your code, which is one of the things I'm most excited about. When I first tried using TableAdapters, which are the, you know… connecting to the type datasets, I was shocked at you know it generated, like, 600 lines of code and I was just, like, I don't want all that code in there then I changed my table and all that code has to regenerated and yak-yak-yak. I just want my code and I'm one of those kind of programmers that likes my code you know, I wanted to be mine, I wanted to understand that want to know what's going on, I want to be one who put it there and the other nice thing about object binding is it generates very little code for you.

It's mostly generating all of that yucky stuff, like, who wants to sit down and put 12 text boxes on a form. So, that's what it's doing, it's generating all of that UI code that you would manually be doing by dragging the controls on yourself. You can though we talked a little bit ago about, you know, how you can just create properties on your objects and it would just work, but to really make it fully functional you do need to implement some interfaces. So, we talked about the error info, IErrinfo interface. There is also an INotifyPropertyChanged, which you can implement if you want the user interface to recognize when your code changes the property.

Ron Jacobs: Also, if you had, like... some, like... When they change, when they enter the ZIP code, let's say, you go often, look up the city based on the ZIP code and you change that which would fire this thing?

Deborah Kurata: Right, and then it would correctly notify the UI so that it would readjust the property otherwise it doesn't really know to adjust, something so it does that, and there are some other fancier things that you can implement if you want but I primarily use those, too.

The other thing that's really useful with 2005 of course is generics, and I'm sure most people have heard about generics and it's really kind of an odd name for, something and I'm sure you are very familiar with it, but generics really do something specific. So, it's sort of…

Ron Jacobs: It should be specifics.

Deborah Kurata: Yeah, shouldn't it be specifics? But it let's you write very generic code that can be very specific and so one of the things that you can do is leverage that. So, there is a binding list and in VB we can call it binding list of T.

Without the 'of' keyword in C#, I don't know how they say that. They so use 'of', I don't know… Yeah, but how do you say it verbally. Do they still say 'of'?

Ron Jacobs: Yeah, I guess people kind of do say, I have never really thought about it, you know, but... Yeah, I guess people do say that.

Deborah Kurata: Say, do say 'of' even though it's basically just the… Yeah.

Ron Jacobs: 'of'. Yeah.

Deborah Kurata: Anyway, binding list of T allows you then to create list of business objects that they know how to bind. So, that's how you would get like a grid type style interfaces by putting your customers into a binding list and then you can bind to that binding list. And that gives you an editable grid of customers. So, there is lot of nice things in there. But it's not perfect. Yeah, there's couple of things that doesn't really do real nice yet.

Ron Jacobs: OK. Oh! Right here, we are gonna be here finding dirt on object binding. OK, what's the dirt?

Deborah Kurata: Well, there are a couple of things. First of all, it does not do radio buttons very well, and I think part of that problem is that Windows' forms does not have a radio button group control like the Web does, and so there is no single control that you can really bind the property to.

So, what you end up having to do is creating a separate property for each little radio button you do want. So, if you had, you know, like, stock options, we are gonna keep it in stock in terms of a product, we're gonna keep it in stock, it's gonna be a special order only or we are going to buy it from one of our subcontractors or whatever.

See, if you have three choices you stored in one field where you can't bind that field and get three radio buttons. You have to actually create three separate Boolean fields and then you have to write the code that maps the one physical field in your table to three separate properties on your object in order to get it to bind correctly.

Ron Jacobs: Yeah, I can see what I would probably do normally, I wanna have one enum in my code and then I would, of course, map the enum to a value that I stored in actual database. Right, and then I would have a property that return to the enum, but you are saying I could have that but I still also have to have, you know, the each Boolean on offer each of these values.

Deborah Kurata: If you want it to auto bind using a radio button, yes. I think the only real solution to that is to have our radio group box like the Web does, where you could bind to that group and it would know then what values to put in it, so that's one thing. The other thing is that you still, you frequently, really wish that you could iterate through the properties.

So, it would be nice to have something other than having to use reflection to give you all the properties of your object. You know, so there will be some built-in language feature that gave you the list of properties that your business object has kind of, like, it gives you the list of forms that your Windows UI has or the list of properties of the controls, list of controls on a form.

Ron Jacobs: Why would you wanna do that?

Deborah Kurata: Well, there are some cases, like, for validation that you might wanna go through if you wanna create your own mapper to your table, because still ultimately even though it's taking care of binding to the UI, you still have to take care of mapping it back to the data. So, if you wanted to write something generalized I can use the word generic can I generals, so now it's generalized.

You wanna write something generalized that would know how to map all of your properties into fields and a table. You have to actually still do that one by one. You know, my LastName property goes into that item, ParentCode, you know, whatever. It would be nice if especially if you did create a constraint for your self that choice measure field names and your property names the same that I could just look through and do that more easily.

You can do it now, but you have to use reflection for it and, you know, we always get worried about performance when you are having to use reflection. So [it would] be nicer if they gave you, you know, like, a little control array kind of a thing for all of your properties and your business objects, so that you can easily, you know, iterate through them all.

Ron Jacobs: Yeah, you know, years ago when .NET first came out and I was kind of, you know, exploring it in the very, very beginning. I looked at the attributes and I thought, these attributes look really cool, like, there's lot of potential there, I am not sure what I would do with them, you know, and I started thinking about, well, one idea would be to use them to help me with mapping to the database right, so I would start putting an attributes, like a database attribute, and say what column this thing goes on, on what table and whatever.

Then I can have a helper class that would look and, you know, know where to put the things, and I actually built one that did that and it was pretty, pretty easy to do but... Yeah, you have to get hands a little dirty with little reflection stuff to do anything about that.

Deborah Kurata: Well, the other thing would be validation one to be nice to use just attributes and say that the validation properties are required comma max length of 15 commas, you know, semicolon here, you know, or whatever delimiter you would want to, just as an attribute and not actually have to, because right now you either have to build some kind of rules, fancy rules engine for some type for your validation, which is what Rocky does in his object-binding scenario.

So, I just create a validation class and then call separate validate method. So, every one of my properties calls whichever validate methods are appropriate for it, but attributes seems like there would be such a cooler way.

Ron Jacobs: Yeah, that would be... You know, that's pretty doable. Maybe I will go write one this afternoon.

Deborah Kurata: Sell it back to Microsoft; I guess you can't do that if you are an employee.

Ron Jacobs: I guess I have already worked there; they won't pay me for anything. They'll say, We already own you.

Deborah Kurata: …and anything that comes out of your head.

Ron Jacobs: That's right. Yeah, so, well, OK. So, that's interesting. Now, one thing you mentioned that kind of made some question mark off of my head when you were talking about the radio buttons, kind of acting differently in Web scenario versus form. Does object binding behave differently in the Web scenario?

Deborah Kurata: Yes, and it's… I kind of touched it and realized that it was completely different and just decided to drop the whole Web chapter out of my book, because it was so incredibly yucky and different and whatever. So, basically it has the ability to do object… what it calls object binding, but it doesn't use data sources window, it doesn't use any other same techniques.

And basically it has… forgot what it's called, it's not an object, I think it's called just an object source, maybe, that you can bind to. But it doesn't really bind to your business object unless they match this whole slew of rules. Like, they have to be public, they have to be, I mean… They have to be both, read and read-write… You can't have public gets and private sets on them for work, and there is a whole bunch of limitations on them.

So, what people like Rocky did is, he actually built his own binding control, because again, unlike Windows that actually has a control on the toolbar, more like the old DataControls from VB5, you know, the kind that you took off the toolbar and dropped onto your form. It's more like that, and so Rocky wrote his own, and I haven't actually looked at the inside of it, but I understood that it was quite nasty, the amount of code that he had to write to actually get all of that.

Ron Jacobs: And, by the way, for people who don't know Rocky, Rocky is Rockford Lhotka, who is another author, actually a speaker here, who will be actually recording one of these sessions with me later this afternoon. So, I will have him ask about that.

Deborah Kurata: Have him talk about that. Yes, have him talk about how much work that there was, because I would been interested to know, too. I'm dying to download it. His work on this is called the CSLA and it's downloadable off of his Web site. Probably the easiest thing is just to search for Lhotka, if you could figure out to spell it and CSLA. You can have him spell it for you, too, later.

Ron Jacobs: I think he calls his framework CSLA.net or something like that. If you search for that, you probably find it. Of course I can always post the link when we post this episode on ARCast. So, I may all do that if I think about it.

Deborah Kurata: Yeah, because that control is supposed to be up there but it doesn't, it's not similar at all in how it works. So, I focus just on Web one for my book.

Ron Jacobs: Well, you know, there is some...

Deborah Kurata: I mean, on the Windows one, what did I just say!!

Ron Jacobs: The Windows one, yeah, you are right. You said the Web one.

Deborah Kurata: Yeah.

Ron Jacobs: OK, but there is some good news here, because sometimes people from the outside, you know, kind of go, Isn't that weird, that here such things work really great in Winforms while it doesn't work so great and works very differently on ASP.NET? People don't understand the kind of way that Microsoft works on the inside, but the ASP.NET team is an amazing team. They have done a fabulous job.

People who are Web people just totally love ASP.NET, but they were kind of, like, off doing their own thing and Windows forms guys were off doing their own thing and they were talking little bit probably.

In retrospect, I wish they would have talked more, but the good news is that's got Gut3 who for years and years lead the Web team, got promoted after .NET 2.0, because he has done such a fantastic job. So, now he is in charge of the whole thing. So, maybe he can pull these guys together and get them better connected, so in the next release won't have these kinds of works on it.

Deborah Kurata: No, a part of the problem, though, is that Windows and the Web don't work the same. You know, so many more issues on the Web side with, you know, because you can't just keep your instance. I mean, you can't keep your business object instance just easy as pie and have it just automatically know how to deal with everything.

I mean, when you are in a Web environment by definition, you are completely disconnected. [I] mean, it has no idea who you were, once it's done giving you whatever page you just requested.

And unless you start sticking your objects and sessions day, which then create some additional work, 'cause you has to make everything serializable.

So, unless you are gonna do something like that, there is really no other way to easily keep your instance. So, the fact that they can bind, do two-way binding on the Web is actually, when you really think about it, it's absolutely amazing that they could even make it work at all.

So, the fact that it doesn't work like Windows, I'm sure doesn't seem like it should matter much, unless should they actually got it to work.

Ron Jacobs: They pulled up a miracle. OK, let's cut them some slack.

Deborah Kurata: But it is hard when you work like I do, where you do a lot of Web development and Windows development, because it's, you know, twice as much learning. It's not just learning how to do it one way and then applying it to the Web.

You have to learn how to do everything two ways and with 2005 that's a one of the most disappointing thing and in general for me is that, the Web has changed so much now from Windows. I mean, in 2002 and 2003, it was nice. You could pretty much, you know, leverage everything that you knew about Windows development and pretty much, you know, other than the controls were a little bit different you can pretty much do a lot of the same things.

But now, with file-based instead of project-based and properties are different, the project properties are different, how you set those up, all the binding is different. I mean, it's… You have to doubly learn everything, and since I have been so focused on learning the one, I haven't spent too much time learning how to do the binding in the other yet, but very soon, because I have to do both in my job, so…

Ron Jacobs: Wow! So that, you know, well, I think they could probably make some improvements in terms of, you know, at least the experience being similar, anyway, but we'll see, we'll have to cut on some slack there, but... Let me ask you one last question and kind of wrap this up, because being this is ARCast we think about architecture and so I'm thinking how does object binding change the architecture? Does it change it at all? Do you think, or is there any impact on architecture of an application?

Deborah Kurata: I think that for me personally most of the systems I had been architecting with, like, VB5 and 6 for example are very much stateless and that goes back to kind of what we were saying before, and so object binding changes that in that it does assume that you are going to maintain state.

So, I'm not sure that object binding itself changes your architecture as much as some of the tools and features and capabilities of 2005 and, you know, the deployment features that it has and all of those kinds of things really can change the way that you architect a system, because you have so many more choices.

It doesn't have to be, you know, for simpler deployment you have Web, for hard impossible deployment you have Windows. So, everybody goes Web, because you don't want to deal with DLL hell, I mean, all that kind of stuff is gone. So, I think it almost opens the door for more architectural choices, because you can pick a Windows app because you want a Windows app, not because you don't want to have to deploy it. So, I think that, that affects the way that you are going to think about how you gonna build your application.

Ron Jacobs: Well, I think there the one real interesting example to me and this is the one which I spent a lot of time studying, which is composite UI application block, which uses a model view controller pattern and that pattern works very well with object binding, because your model persists, right. You always have the model and they have this notion of workspaces in the composite UI block.

So, there is a place to stick those things that invoice objects, the customer objects and views can just bind to those very, very nicely. So, that's kind of a prebuilt architecture, if you will, if you go, "I don't know where to start with this." Well, you can pick up something like that composite UI application block and kind of go with that architecture and actually building a much larger thing called smart client baseline architecture around that, so have all the kinds of things, few were, like, offline support and so forth, but... Hey, well, they have done some fantastic work there, and so I encourage people to go look at that. But thanks, Deborah, for coming by today.

Deborah Kurata: Sure. Thank you for having me.

Ron Jacobs: You are welcome. Deborah Kurata, ladies and gentlemen. Deborah, we finally got the show on the air. After that failed podcast library first podcast. I don't know, some kind of glitch happened with the recording thing, and later on I went back and looked back at it, it had nothing. We talked, had this nice talk for a long time, and got nothing. But, hey, I don't make those mistakes anymore, because now we know what we are doing here on ARCast.

I am so glad to say that. In fact, I had a nice note from Patrick out in Greece, and Patrick said, "Hey, Ron I just want to let you know you changed the boring commutes to and from the office in a great way, learning about all this stuff I should already know." Well, hey, thanks, Patrick. That's why we are here, that's all, all about We are trying to just get the knowledge out to you. So, keep listening here on ARCast.