Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

ARCast - Expert Business Objects with Rocky Lhotka

34 minutes, 0 seconds


Right click “Save as…”

  • MP3 (Audio only)

Business objects – ancient history right? I mean haven’t we all figured this out by now? Well according to my guest today; Rocky Lhotka the answer is no. Many people are still writing really ugly code and everyone knows it, but what is difficult is how to do the right thing. Well my friend, Rocky is here to help you so take advantage of this opportunity and learn something about business objects


If you like this episode check out these







(in Sec.)

Ron Jacobs

Welcome, welcome friends to ARCast. I am your host, Ron Jacobs coming to you once again with architectural wisdom from the fount, that is VS Live, San Francisco where I had a great time talking to many of the speakers there and on today’s show, we are going to hear from, well, the guru of Business Objects, Rockford Lhotka or Rocky as we like to call him, as in Bullwinkle and Rocky, no just kidding, just kidding. I am sure he’s heard that a million times.

So he is, Rocky is, the author of Expert Visual Basic.NET and C# business object books, which are really just terrific stuff, speaks at many conferences around the world and just an all around good guy whose passionate about helping YOU to do the right thing with objects “Stop putting all that code in your UI, that’s a bad idea” Let’s give it up for Rocky Lhotka.



Hi, this is Ron Jacobs and I am here at VS Live with Rocky Lhotka, who is one of the amazing VS Live speakers, fresh in from the cold North of Minneapolis or was it cold there?










Oh, it was not cold there we have had an unusually warm winter.

You are kidding me.

No, 57 degrees couple of days ago.

That is, that is so bizarre, means I am sure you like all the global warming people are going,”See! I told you, I told you”.[laugh]

And what’s funny is, if I fly into San Francisco its 55, so it’s warmer and in Minnesota than San Francisco in January.

That is freaky! Truly freaky.



Well you know, it had to be like raining here, I have been, you know, it has rained, almost every day for the last 6 weeks in Seattle, so I am really getting annoyed, [laugh] I come to sunny California and it’s raining here too. But what can you say? So, alright, but we are here at the most wonderful event in the world of course VS Live and you do lot of the VS Live events, don’t you?



I do most of them. Really enjoy it. Lot of the people who have attended have come back many-many times even, fly here from all over the world and it’s just a good conference and lot of fun people.







Yeah I have done a bunch of these, I think, I did 4 or 5 of them in the last year and just a few, you know, I didn’t go to Vegas. Did you go to Vegas?

Umm...No, I did not.

See. We missed the fun one. [laugh] Cos you know what they say about Vegas, right, well, anyway. We don’t want to go there because, my wife might be listening. So anyway, [laughs] really I didn’t go, really. [laugh]

Alright, but what are you talking to the folks here at VS Live this week?










Well mostly I am talking about object oriented design and building distributed systems using objects.

Ok and isn’t that like ancient history now? Haven’t we all figured this out? By now?

Well YOU would think so. Everybody wants to use objects and in fact if you are not using an object oriented language like VB or C# in .NET or within… “Bad you”, right?

Yeah alright, “You are very late man, you are way out.”



But yeah, as we said I speak at lot of these conferences around the world and I will often ask the audience that I am speaking to that how many people use object oriented design in their daily work, now when they sit down to build a system, do they really use object oriented design to design their system? And only about 30% typically said that they do. So that means over half, well over half of the people in the audience are not using object oriented design to build their applications.



Well that’s kind of scary because it makes me wonder, you know, if they are not using object oriented design, what are they doing?



Well Microsoft has this really cool object called the Dataset, and dataset lets you go to the database, get all of the data you want into a nice tabular container, and then you can write all of your code, well behind the UI, actually. Because if you look at both window’s forms and web forms, again Microsoft has done this really nice job of having a real rich eventing model and nice wrapped tools. So you can just jump in, double click on a button, and there comes a code window. Now this used to be called VB3 style coding but now you could do the same thing in C#, and most people do. [laughs] I think, I suppose it’s a RAD development, may be.



So, so you, look in that code behind file, behind, you know, open the button click and you find ten thousand lines of code that go off and do a bunch of stuff and connect the databases and deal with datasets and…. So you are using an object oriented language and you have methods that you are doing, but really not getting into breaking down into the kind of business objects that you have become known for, being the business objects guy. How did you get known as that anyway?



Um… Well, I guess over the last decade or so I have been writing books and speaking largely on this topic. This is, this is what I get excited about, it’s my area of passion and, and I really, am driven I think, because this model that we are talking about of writing all of this code behind the UI is a flawed model. And everybody seems to know that it’s a flawed model but it’s not always clear how to do something else.



And, it’s so easy to do… you know, put the code behind the UI and you say, “Well! You shouldn’t do that”, and people say “Yes, I know I shouldn’t do that and then… but how?” right! And objects offer an answer, I think this is the real key.



Speaking of books, you know, I had this idea the other day that, you know, I saw in news of how big controversy about this guy who wrote the book “The Million Little Pieces” and he was on Oprah and his book was featured in the Oprah Book Club and I thought, well if Oprah can have a book club, I should have a book club. [laugh] I am going to have Ron’s ARCast book club and you know, so may be on your next book, if it’s good, then it might make my book club, We’ll see about that. [laugh]



I hope it’s good; it should be out at the end of March. So, you know, it will be coming up soon.



And Yeah, then may be all of the ARCast listeners will go out and buy it and you know, set sales records and make the top 10 lists, and whatever right? So that’ll be cool…



That’s what happens with Oprah, right! [cough]And these guys transforms their lives. If you can transform my life, I’ll go for it



Ok, as long as you promise not to lie in your book ok? [laugh]

Alright. So, but. I have never written a book. I have written some magazine articles. But I can’t sit still long enough to write a book. That must be tough.



It does require a lot of sitting, [laugh] yes.



Oh, I get an idea & I go and speak at a conference and write a blog post and make an article and that’s about as far as I get.



Well, it is true, writing, writing an article can take about a week, two or three week, you know, in that range. So it’s a relatively achievable thing. Writing a book is more in a six to ten months range and yes, it’s a pretty big commitment. And I think to write a book there has to be something you have to be passionate about doing. Books don’t make a whole lot of money either unless you figured on Oprah. But, so it’s really is a labor of love, I think.



Ok, that is just twisted. [laugh] You love objects that much and you’re just like, oh, I totally love this.




I do. [laugh] I am sorry but it’s true.

You are a geek; you are a big time geek. [laugh]



Well, that’s ok people love all kinds of everything.

So, so. Well, you know, getting back to this object design idea, you know, I remember when I first learned C++, it was in the early 90’s and I was working here in Silicon valley with a bunch of hard core C programmers, you know, and they brought in a instructor, we spent two weeks in a classroom and these hard core C guys had a very tough time, I mean, they really! They can write some great C code, but, but we just start talking about classes and inheritance and polymorphism and they are just, they couldn’t get it.



But, I now, I have been doing it for couple of years and so I got it pretty easy, you know, came like to me naturally, but, we have this idea that we wanted to take everything in our system and convert it into objects. And you know things like customers and invoices and purchase orders and sales and everything, just, you know.



So, first we made a customer object and then we thought well, you know, customers have invoices so I have an invoices object when you go; I want my customer invoices so I have customer dot invoices, you know, blah… blah… blah… and… So pretty soon you had customer dot invoices dot line address dot this dot that dot the other thing and then you find that you wanted to get a customer object just because you wanted to display their address and you don’t care about the invoices. You got to get the customer object, it takes like three minutes and later you can practice huge object with everything you ever might, you ever want to know about a customer and you are done. But, didn’t work so well.



No, it doesn’t. [laugh] I think everybody starts there. And, I think it’s natural because all of us spend so much time working with data and understanding how databases work and ER diagrams and then we start describing objects often in terms of entities. Well you say customer object is customer entity and then the customer table in the database is a customer entity and so may be, everything becomes defined by data and I think that’s fundamentally flawed. And I say this, I was where you were. I have been there; I have done all those things too, right! and you run into one of these road blocks.



And the answer I believe is that objects are defined by behavior and so when you sit down to create your object model, you should as much as possible, ignore the data as that’s not the important part and instead you should focus on what’s the object, what’s it supposed to do? So your customer object has a mission in life so to speak, right! And it should be a clearly defined mission.



And I say this because if you think about you or I, if we come into work in the morning, you have got 18 different things to do with conflicting priorities, that’s stressful and it’s not fun. And versus if you come into work in the morning and you have got 1 assignment very clear priorities is a lot less stress and a lot more focus. Now in an object that’s ‘stress’ really translates into convoluted or complicated code.



So if you look at the customer object that’s designed to do 18 different things, that looks like lot of switch or select statements, that looks like a lot of if-then, your conditional branching code and you can’t just look at the object and say “Uh, I know what it does.” Right! You have to trace the code.



In order to figure out, well in this case it does this and in this other of case it does that. Well, shoot at that point you could have just stuck with C. Right! A FORTRANer, yeah, regrets spaghetti code in any of those languages just as well.



Well, so, if I am going to write some objects and I cannot start with data, how do I approach that? You know. I guess I am thinking about the customer object’s mission in life, what is that? I mean, I suppose it wants to make sure that it’s got correct and up to date data so if the real customer that it represents down the world moves and a human needs to tell what the new address is so probably wants to make sure that database that stores it’s terrible state would be up to date and may be, I don’t know. What other things would a customer object live for?



Well, that might be a use case. [Ron: Ok]. Really all these… the, an object mission in life should come from a use case. [Ron: Ok]. Or if you are Agile could be a story. [Ron: Yeah, alright]. So you sit down with your business users, your stakeholders, the end users that understand the business itself and you say what do you need your system to do? And one of the things they might say as well is that we need to maintain our customer data. And you say, Oh ok, so tell me how you do that? What are the different stories or use cases when we sometimes need to add customer, sometimes customers move so we need to update their address and so forth. And you go through this process of collecting their story and then you decompose it, every…, any form of object designed ends up going through this decomposition process where you try to identify what are the, I suppose actors is a good word, actors in the system and what do they do? And so customer might become actor but then in this case the customer responsibility or mission in life as you say, would presumably be to record valid customer data.



So, this is, well you know, what they taught back in school you know, you take the nouns those are the objects and the verbs are the methods, you know. [laughs]



Oh, that’s a totally wonderful technique. As a starting point. [Ron: Yeah] But, you kind of flow from there? And, this kind of flowing with this customer thing, the next thing that you are going to find out is that, you need to get the list of customers. [Ron: Hums…] Right! Because for the end users, before we go and edit a customer we have to find the one we want to edit. So now you need a list of customers and you might say, “Oh I have got this customer object I’ll just create and now we have got generics, Right! So create a list of customers and populate it and there I go”. Right! But, how many fields of data are in your customer? Could be a 100 or 200 right? [Ron: Right, right.] So loading a list of customers could be really expensive. [Ron: Especially if all you need to do is put names in the combo box or something.] That’s exactly! Right! So intuitively, all this is dangerous. [Ron: Sure]



But if you step back and think about it again behaviorally, the behavior of this customer object is to essentially collect valid customer data. [Ron: Hum…Hum…] Well, we are not collecting data, are we? We were displaying a list. So we would be misusing this object. It’s like you are coming in and asking an employee who is assigned to do one job and say,” Oh, can you do this other job for some a while?” “Like I don’t know how to do that other job. “ “Well Do it anyway! “ OK? [Ron: Yeah.] It’s better if you hire another employee to do the other job and in this case, it’s better to create a customer displayer or customer info object whose mission in life is to display a subset of customer data. Totally different mission, totally different behavior. Now the interesting thing in this is, where things really get fun is they both have the same data. Don’t they? [Ron: Yeah. Yeah. See, that kind of rankled some object oriented people. “Oh! That shouldn’t happen.”] Well, this I think reflects how relational data theory has infected the object design world. I used the word infected. [Ron: [laughs] It’s contagious.] You know, I can tell where my bias lies.



Well, you know that’s a real interesting perspective. So what you’re saying is that sometimes our tendency is to begin with the database and kind of look at the database and see how it modeled the world and in even borrowing it’s normalization concepts and all of that [Rocky: Right!] and saying, “Well, that seems to work pretty well there, so we have to make our objects kind of similar”, and it begins to break down. It’s kind of interesting how the inverse also happened and that people flooded with the idea of objects are so great why don’t we have object databases? [Rock: Hum…That’s true] Those kind of broke down too, didn’t they?



Yes. Because the object concepts don’t seem to map well into efficient storage and retrieval of data. [Ron: Yeah] I do think its two different worlds. But, you know, what's kind of scary about this is, most people use UML or at least the class diagrams scheme out of UML when they do their object design and if you take your database design and print it out, hang it on the wall, you know most people do this. Right! But then take your object class diagram print it out, hang it on the wall next to it and take like two steps back. Can you tell the difference between? [Ron: laughs] They look the same. And so all of a sudden it becomes crystal clear that our primary object design tool leads us to think about objects, the way we think about database tables. And I think this is a problem. So I am a fan of CRC design instead and class responsibility and collaboration, which is a very old but unfortunately not very popular scheme for doing object analysis and design.



Ok. So since it’s so old and arcane probably many of our listener’s won’t know what that means. So class responsibility collaboration, so, the responsibility is that like the mission in life of this thing, what it has to do?



That’s how I portray it. I think in classic CRC design it’s a little different but, the way I think about it is you think it is a class so you give it a name, a customer or invoice or customer list or something and then you say what is its mission in life, what’s its responsibility, which I think should be a say 6 to 8 word phrase. I mean that keeps it focused. But, again we want happy objects. [laughs][Ron: No stressful objects out there.[laughs].OK.] You got a very clear focused mission. What are the things it’s kind of hiding behind that mission is the behaviors. In order to fulfill the mission it’s going to do certain actions, you can kind of think of those may be as methods or properties but so it’s got that aspect but it also has collaborators which are other objects that help it do its job.



And so you can think of, something like an invoice which is relatively complex or can be. And, I’ve written an invoicing system years ago, and that was procedural. This is … pre-dates object orientation at least in my experience. [Ron: You don’t look that old though[laughs]] Ah…You’re doing this almost 20 years. [Ron: Wow, OK, I am with you in that case. We are about the same(experience).][laughs] I think it’s about the same time for us. [laughs] So invoicing can be really-really complicated.



Then you can write an invoicing object and put all that code in one place and you could have an invoice object that’s really-really complicated. And, did you gain anything? No. Nothing at all, so it’s. But if you instead decompose the invoice process itself then you could have a lot of smaller objects that the invoice collaborates with to calculate prices, to calculate discounts, to update the customer sales, figures all of the things that go in doing invoicing. But when you look at invoice class it ends up looking relatively simple.



You know it’s funny when you describe it that way because it made me think about the whole reason why we went to object oriented in the first place is because as programs became larger and larger and more and more complex, it’s like you get a buffer overflow when your brain tries to absorb what this thing does? You know, cause you only got so much brain workspace, right! [laugh] And you can only understand so much of a problem at once.



And… So the big three of object orientation were polymorphism, inheritance and encapsulation. And encapsulation was key because it helped you divide the problem up in the mind sized chunks. [Rocky: Yeah.] So if I could understand, I could look and focus on one aspect of the problem with a mind sized chunk because if the object was mind sized than I could do that. But once you know, if I build an all encompassing invoice object which could do every possible thing an invoice object needs to do I am right back to buffer overflow of the brain because I can’t understand the whole object at one time.



Yes, that’s exactly right and it’s easy to loose sight of that. Because you think, I have got an object and it starts out small, seems mind sized but then it grows slowly over time and one day you wake up and your object has become a monster.

[Ron: You have to kill it, it must be killed.[laugh]] Luckily we have a trendy term to solve this though. Because now you can refactor your object. So now it’s ok again because you are refactoring.



Well that’s when they go, “I have this code that smells we need to … we need to refractor this man.” That reminds me of Peter Provost, I did a web cast with him and Bryan Button. They are big tester and development type guy and it’s just amazing for me to watch them do this exercise about how they, how they say, basically their codes talk to them. And it’s just a way of saying you know, as you are building the thing you kind of intuitively asking questions, does this object makes sense, has it overstepped its bounds, is it getting too big, you know then is it duplicating functionalities that really belongs somewhere else? And refactoring is just saying, I am not afraid to change this, break that object apart, break it into 2 or 3 or 10 objects if you need to.



Yeah, that’s absolutely right. These concepts are called dovetailed together. And, what I think is happening at the moment is that there is a resurgence. I mention that CRC is quite old, but it has never been the big popular technique but I think there is a resurgence. I think Agile and XP and test driven development, and the behavioral concepts of objects all fit together in kind of little world that at the moment is on ascendancy. People are interested and that’s fun and hopefully will move the industry forward and help us build some cool software.



You know it is interesting because when I think about, I have done the little exercise where, you know, writing out these yellow cards and stuff with other people and stick to them all over the walls and you know checking everything out but I actually even do that kind of mentally when I am designing something is… I imagine, you know, the little objects like they have got names like that’s George and that’s Sally,[laugh] and Sally does this and when she needs to do that she has to ask George to help with this part and, you know, and Sally knows what her name is but George knows how to update the database. Whatever. I kind of mentally think about it that way, I know it’s kind of scary.



No, its… its… there’s actually a word for that. It’s actually anthropomorphisation which is taking inanimate objects and giving them human attributes, Disney does this lot time. [Ron: Sure] candelabras and they dance surrounding and sing songs It’s a wonderful technique for doing behavioral object design. Because you know, you can actually envision is this object happy, is it social, is it, you know, talking and playing well with others? Get some good laughs out of it. It’s corny, but it’s useful.



It also helps me to focus more on the behavior and collaborations rather than just the data. The data that the state of the object holds becomes like a supporting detail. [Rocky: Yes] An object holds whatever state it needs to do the behavior but it shouldn’t hold more [Rocky: That’s right] than it needs to hold.



That’s absolutely right. And similarly then multiple objects might need some of the same data to do the job but that’s OK too. That’s really like, the object relational mapping is often characterized as a way of loading data out of the table into an object, that pretty much looks like the table. And if that’s all it is, that’s kind of boring right? But if you start doing the object design we are talking about here then object relational mapping becomes truly interesting because the shapes of your objects can be quite different than the shapes of your data in the database. You can have many objects using the same data or lot of interesting relationships that way.



Ok, so the last burning question. Service Oriented Architecture! People are going, “Ah! We are not building objects any more we are building services.” And you know we are passing around XML on the wire, if we do have an object it’s just like a container for the data that we were pushing around. How do these concepts fit together?



This is something I think about quite a bit. I mean obviously, service orientation is also a very trendy popular thing. I’ve blogged about this a fair amount. I think the lot of the problem that we face is actually based around language or semantics. In that, you mention, “Oh! we got this object, let’s send it across the network to a service.” But that’s not what’s happening. Objects never go across the wire between services; messages go across the wire between services.



And, there is this illusion that they’re an object because when you are programming in VB or C# we end up, you are given this proxy that’s generated for us but really what happened is that Visual studio took the description of this message and created for us a ‘Object’ which I think may be better characterized as a structure. Cause inside an object it has no behavior and it’s just a container for data that’s convenient for us to consume or create messages and so services don’t exchange objects.



And… now on the other hand, you have to implement the service itself and so if I am sitting here writing a service I am going to accept a message from some outside source and then I am gonna do some hopefully useful work, and possibly produce a message in response. And the real question then is how do I write the code that does that interesting work? And I might write that using Linear programming techniques, I might use procedural programming techniques we did in Pascal or C or I might use object oriented techniques in order to again create body of this service. But what comes and goes is just a message, it’s just XML.



So really, you know, we still doing objects but just gonna need objects on either side of the wire because sometime people will say to me, well ok lets use our… my favorite customer object. I have got the customer object on the server side but maybe I have a smart client application on the client side. I might gonna have a customer object over there. Should I build one day customer object that lives on the server side and I also deploy it on the client side? Is that a good idea?



Not if you are doing service orientation! No! I draw this line because I personally still think that client server technologies, some of the client server concepts that we’ve explored over the last 10 or so years are totally valid. And if you are creating a client server system where the server is part of the same application as the client, the same application that’s happened to have a network between them then I will go with you and say, “Yes, you can have the same customer object on both sides.” In fact that’s what I talk a lot in my business objects book. But if you doing service orientation then the mind set is entirely different because service orientation essentially says that any time there is a network boundary, there you, at that point have two applications.



So instead of one application with tiers, now with service orientation you have a server application, which could have many different consumers. One of which might be your client application, it’s a smart client. Well now they can’t share the customer object because they are not the same application. And so you don’t want the dependency or coupling between the two. So the server needs to have its own customer object, it’s own internal implementation and it consumes & sends messages that are following a clearly defined schema and the consuming application, which is your smart client, is an entirely separate thing, which just happens to be calling a service. But, its implementation is really its own business.



Well the other thing that it seems to me is that the behaviors that you want at the server side and the client side are going to be different. Because on the server side you might have a behavior like “save yourself in the database”. Right! But on the client side that wouldn’t be valid at all, because there is no database for the client side. All it has is, call the service that saves you in database or whatever. Right?



Well, that’s true but it’s a little dicey. Lot of people will tend to look at service orientation as being a way of getting code reuse. And I think that’s a flawed way of thinking about it because, you are right! On your ‘server side customer’ certainly there’s going to be code dealing with persistence. But remember that the server side application is a standalone application. So it can’t trust any consumer. So it’s got to validate all of the data that are coming in because Customer is a trivial example but if you take a sales order or something else you might have to recalculate taxes because you can’t assume that any of that was done right?



Right! And then at the same time your smart-client that has this customer object. Well if it’s a smart client, it needs a rich user experience and instant validation and so forth. Well it’s going to have do validation in a variety of the same logic. Of course it’s different because it’s going to support data binding and a bunch of things the server one doesn’t. But if you think about what I am describing here, there is a large chunk of overlapping functionality, in the other separate objects. And so really service orientation, if you look it that way, is going to cause you to write duplicate code. It’s by definition.



Interesting. Well. That is fascinating stuff and I look forward to your new book. And so, you know, now here’s a problem. If I start a book club I am going to actually have to read some books. [laughs] so I can recommend them or not. [laughs] So, but I am looking forward to reading it so maybe you can send me a draft.

[Rocky: We’ll figure something out]. All right, Well, thanks Rocky for showing up. [Rocky: Thank you very much.]



Rockford Lhotka. Ladies and gentlemen, Business Object Guru, Expert Business Object guy. Thank you on ARCast. You know there is so much to learn about this and I am so glad that I have guys like Rocky around us to give us wisdom on this.

Here I wanted to give quick thanks to Robby and Daniel from dt.com. Daniel says, “Hey Ron, I just wanted to say keep the ARCast coming. They make us standing room commute everyday in the Central London actually productive.” That’s the point. Send me a note to ron.jacobs@microsoft.com. Let me know what you think. See you next time on ARCast.



Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • I have been waiting for this on since you mentioned it on Deborah's last show.  Anything with Rocky is always an experience.
  • Ron Jacobsrojacobs Ron Jacobs
    Yes - Rocky rocks!
  • Dating SitesDating Sites

    I know that is a research that tell the people who always play game more than six hours than the other people that never play games.

    <a href="http://www.panix.com/userdirs/blog/free-dating-sites/">Dating Sites</a>

Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.