Hmmm... perhaps I missed the last round of kool-aid, but, exactly why is not setting the internal variable in a property setter a bad idea?

Of course, you answered the question already. I would ask, if not the property setter, just where is it supposed to happen? I really do want to know! Heck, you just got me using property setters, rather than just having a public field, this year, and now this! My neck is hurting from the whiplash!

Ok - I get it. Should you literally change the value between what it comes in as, as a parameter, and what it sets the internal variable as (i.e. SSN comes in as AAA-BB-XXXX, you remove the dashes, and it gets set internally as AAABBXXXX).

Of course. That is part of the business logic. Next question. So long as the business meaning stays the same, not a problem.

I must say I agree with you on this topic; I don't know anyone who doesn't. I have developed a few applications in VB 6 (yes, VB version 6) and C# using this approach.

It IS very, very difficult to implement in any but the most simple of applications, however. Unless you are very careful, it is very easy to have all your layers working properly and then still find business rules being placed in screens, forms, and services. In the majority of business applications that I've put together, the same business object is used in multiple screens, forms, and services. The problem is that, usually, each one requires that different - conflicting - sets of business rules be placed on the same object. There are many design choices when faced with this situation.

1. You can wire each screen, form, or service with the rules. Obviously, some of the rules will be duplicated. This is exactly what we are trying to avoid. It is, however, the easiest to implement; especially since many UI actions occur based on the results of some of the business rules. It's a trap! Don't fall for it.
2. You can clutter the object with "condition" settings and apply rules based on the conditions. I've seen this done many times and I hate it. Talk about a maintenance nightmare...
3. If the screen, rule, or service requires a special set of business rules, you can create a separate business object for each; inheriting from the business object that provides the most complete set of rules for the designed purpose. This sounds good. Business Objects contain all the business rules. Screens, forms, and services don't have duplicate rules to maintain. Maintenance can still be a pain in some cases, though. When a new rule must be created, care must be taken to position it in the right business object so that it is inherited only where required. It is very easy to find duplicate rules in this setup after a few months of maintenance kicks in.

Of these options, I like number three the best. But I find that most people first choose option 2, then find themselves wishing for something different.

If anyone knows of other options or approaches, I'd love to hear about them.

Now all this said, I have to laugh at this statement from your post, Rocky:
"The resulting applications are very fragile and are impossible to upgrade to the next technology (like .NET). Today, as we talk, many thousands of lines of code are being written in Windows Forms and Web Forms in exactly the same way. Those poor people will have a hell of a time upgrading to WPF, because none of their code is reusable."

This strikes me as "funny" because every time I've upgraded an application to the next technology, it required a complete rewrite from the ground up! The rewrites aren't necessary because business rules are placed in forms, screens, and services - but because the code wasn't transferable to the new technology! Even upgrading from .NET 1.1 to .NET 2, or .NET 2 to .NET 3, how much of the code is going to transfer cleanly? That's just code. Usually an upgraded database is involved, too. SQL Server 2000 to 2003 or 2005, for example. Coding technology, databases, and even hardware are changing so rapidly that keeping up with it all is practically impossible.

Really, does ANY of this really matter?

You're saying that if I ask the user for his name

name = askUserForName(); // say user enters "r.lhotka"
user.name = name; // user.name is now set to "R. Lhotka"
assert(name == user.name); // may fail

You think that we should NOT expect such an assertion to pass.

Is this really a no-brainer? Well, it does seem to violate many of
our assumptions about assignment and equality. It also means that
the UI programmer needs to know whether .name is a property
or a field, and basically be a little more paranoid.

Why not just provide a method, like, say, void parseName(string), or even
a static method, like string cleanUpName(string). Why not separate
the model from the view with a thin presentation layer. Why not
provide the UI developer with a customized text box that does the conversion
automatically. There are lots of different ways of solving this. You could
even credit the UI developer with a little intelligence, and let him
add the functionallity himself, like in the browser, with javascript --
something a business object can't do.

Having the id be SOP123 might be a business rule, but having sop123
automagically convert to SOP123, might not be. In a model view
controller architecture, such a conversion may be viewed as the
responsibility of the controller, not the model.

If you insist that properties can change the value in the setter, so databinding
needs to account for this, and I insist that we should use model-view-presenter
to handle these conversions, so it irrelavent, where are we?

I've always liked your ideas because they have a real practical edge. That's clear here. Why not use the data binding mechanism that Microsoft has provided? Its probably the way to go.

But its not all gravy, is it. What if I don't feel like writing MyOwn.Web.MyOwnDataSourceView, and the other DataSource, DataSourceDesigner, etc., complex classes that are required to eat this particular _free_ lunch. Not all my projects are going to be CSLA applications.

While you stated: "if changing the value in a property setter is prohibited by convention, then it should be prohibited by compiler", I'm guessing that you don't really believe that "if it passes the compiler, it's ok" is a reasonable design heuristic. After all, the compiler allows public fields, which you feel are "bad".

The model-view-presenter is obviously a java type thing, and we really don't like java type things. But writing presenter classes is not that strenuous and can give a lot of flexibility. Its particularly useful for those test first twits. Sometimes if a business class is worth writing, its worth writing a presenter for. Whether its "just silly" depends on the perspective of the developer. A presentation layer, taken seriously, may enable richer UI screens without putting undue stress on the business object code or the UI code (e.g. MS composite ui application block). It also avoids the need to redefine presentation logic as "business rules."

If there is an impedance mismatch between the domain model and the database, surely there is a greater one between the user and the business layer. If I have a business object that can respond to a wide array of date formats, just because they are convenient for the user, am I not cluttering up my business objects with "business rules" that serve no other purpose than massaging the impedance mismatch between the UI and the biz layer. Is data binding really so compelling? At least the TableAdapter lets me avoid REAL work.

Properties use the syntax of assignment and appear, to me, to imply the semantics of assignment. When the following code passes
obj.type = "rx";
assert(obj.type == "prescription")
we may be violating the semantics of assignment, and, we may be putting presentation logic in our business layer. I may decide that the convenience of databinding justifies these "sins," but decide to go ahead with it anyway. Or, you may feel that properties do not imply assignment semantics, and believe that everything that does not go in the view is a business rule. You might even decide that you're just going to adopt this particular view within the confines of your CSLA goals. But perhaps we shouldn't pretend that property assignments that don't behave like assignments are, across contexts, obviously ok. This wasn't the case for the MS databinding guys. If it was, you wouldn't even be blogging about this. You'd be doing properties -- your way -- and would not really care if your way was the same as my way, and I wouldn't have spent the last hour on this comment, whose ultimate utility is exceedingly doubtful.

I think the central point in our disagreement is that I consider some of the calls you’re making to be context bound, that is, reasonable with a certain context, whereas you feel that their validity may extend further. I feel that assertions like “changing the value in properties in the setters according to business rules makes good design sense” is about as valid as asserting that it is wrong to do so. It is all context bound. I just don’t find these absolutes very useful. I never felt the need to have only one return statement, and I’ll use a goto statement maybe once a year without any guilt.

Yet the comedy plays out on a much larger scale beyond my conscience. The soa guys and the object guys, the test first guys and everyone else, the c# vs. vb jokes that are never funny. The oop crowd can be particularly annoying, as when, for example, someone tells you that a company and a person should have the same parent object since they both have phone numbers, satisfying the “is-a” rule for “contact.”

So, I’m reading your blog and come across this entry where you include the email from an oo guy, in full purist mode, grinding his teeth and frothing at the mouth because you’re both oo enthusiasts, yet csla is such a violation of good oo design. So, is the guy right? I think by the Westian Object Thinking view, he might be. But on the other hand, CSLA is a spectacular use of oo _technology_ (inheritance, polymorphism, and the other one, oh yeah, encapsulation), rather than an oo design (for behavior) show case. Well that’s the way it seems to me. Its not better, or worse, its different. Its solid, context bound design.

So, then, what is the context. Ahhhhhh. The context is “how to do object thinking in a Microsoft world”. One would think that, given all the oo rhetoric, there would be a legion of top guys trying to solve this problem. But there is only one. You. That’s why you’re so important in the push to have Microsoft data-binding work with objects. Why is that?

It’s because the visual studio and .net productivity tools are not really designed for object oriented programmers. What Microsoft wants to create and sell, and what business managers want to buy is tools for creating software that do not require a software developer. Well, the reason most oo designs (including mine) suck is because oo design is hard and requires talented developers who are expensive and probably require expensive managers and facilities.

So, if you’re doing web development, what do you do? You drag a grid on web form, and 10 clicks later you’ve got a page that allows you to handle a fair number of use cases. It takes 15 seconds and you’ve got a layered application [view -> data binding layer -> data-table layer with business logic -> data-adapter layer -> data store]. But, I say, its a crap design. I’m going to make a five layered [view -> presenter -> domain -> data access -> data store] object oriented version, with a fully oo compliant domain model, it will only take 6 months and cost $95,000. Not at this company pal, says my boss, and its over.

This is not indented as an anti Microsoft rant, its merely an explanation for why the data-binding to sql server with in memory data table technology (that is so sophisticated that it knocks your socks off) works so very well in visual studio, but why binding to objects, which is widely espoused as the only responsible data binding scenario, a trivial problem by comparison, has been so piss poor, even if we are getting real close. Its 2006 forchrisssakes. In a very real sense, oo design, and data-binding to objects just isn’t the vb way.

Enter Lhotka, the visual basic guy who likes oo. If you were a smalltalk guy, you would never have created csla. It takes a vb guy to do it, or at least that’s the way it seems to me. I was a vb user from vb 3 to vb 6.

So, to me, csla is like a wedge inserted into the ms workflow designed to create enough space for me to create a decent object model without loosing my job. How is this accomplished. The data store is fine - sql server. The data access layer is split, much of the orm goes into the stored procedures in the data store, and the db access, object creation, and hydration goes in the business layer. Is this business logic? Well, _I_ don’t think so. Does that mean I’m going to drop csla, or push all this logic out into a service or gateway layer, and implement my own data portal? Nope. The data portal mechanism is friggin cool and a use of oo technology that is beyond coolness. No, I’ll use csla, I’m all set. But I’m not going to pretend that data access and data gateway code is business logic, nor that static methods that trigger data access is consistent with oo dogma.

On the other side, the presentation layer is split, with much of it going into the business layer, and the rest going into the view. Now, all uppercase ID seems like a business rule to me. The conversion to uppercase is a business rule candidate. Shoot, its your business, you make the rules. It has a presentor/controller feel to me, assuming that the data is coming from a UI. But we already have presentation logic in our business model. Sure we do. n-level undo. Parent classes that support data-binding. In fact, as the data-binding from MS becomes more compelling, more presentation logic creeps into our business layer, and becomes “business rules” - like exposing data binding aware broken rules collections. Am I going to throw out csla because of all the presentation logic, and write presentation classes with undo capabilities? Nope. Am I going to have a presentation layer on my next java or non-csla .net project. Probably. Will I use data-binding? presentation classes? both? Maybe.

Data binding is cool, but it has been a double edged sword. It has not really been oo friendly. That might be changing. It is not friendly in web forms. I haven’t looked at WPF, but ValueConverter sounds smalltalk-ish (ValueAdapter), so maybe its more object friendly. A csla business object is chock-full of presentation and data access logic. Shoot, it’s got a DataSourceControl at one end and a SqlDataClient at the other end. Like a huge chunk of the code (behaviors) in my business object is determined before I even pick up a CRC card. In fact, if you want to do object thinking at all with csla, you kind of have to ignore the presence of all this data access and presentation logic.

So, yeah, data-binding is cool, and you can bind your objects directly to it -- as long as you’re ok with having presentation logic in your business layer. Static class data access methods and fully encapsulated data portal mechanisms are fine -- as long as you don’t want to use mock objects to avoid hitting and rehitting the database in your unit tests. A presentation layer is silly, but only as long as you have data binding on one side and csla business objects on the other, and are using the specialized csla data source control for your web apps. A data access layer is also silly, since you can inline data access code in your objects. And finally changing the values assigned to a property is ok, as long as it is in particular business object scenarios, but probably not ok if the property in question is a numerical property of some object involved in a numerical algorithm or simulation – if I put 3.14 into a property, it better be 3.14, not 3.141592, immediately after the assignment, on a single threaded object.

Although I’ve asserted that csla business objects contain presentation logic and data access logic, and this might appear as a criticism, I understand it as a strength. As you have suggested, I can put all the data access code in a separate assembly if I want to, and having UI compatible business objects really facilitates ui development. With Csla business objects, data-binding in front and sql server behind, I have a fighting chance of developing an object model without cutting off my nose to spite my face, and justifying my existence to my manager who can build a prototype of enterprise applications with data binding and sql data sources in a couple of hours thanks to the boys at Redmond.

Thanks Rocky. I hope I haven’t come across as disrespectful.

That's why every dose of Fowler should be followed immediately by a dose of Lhotka, the “where the rubber hits the road” software theorist. You're a necessary voice in the MS world.

I'm going to pick your nit-pick regarding presentation logic in csla objects. You don't do it, and you don't advocate it. That's clear. The basic point I was making about binding to csla is that it is like the 'dark side', it draws the innocent and traps them. It takes inner-strength to use the power without being consumed by it. If you scroll up on this page, you'll find the following comment from a CSLA user:

> In the majority of business applications that I've put
> together, the same business object is used in multiple
> screens, forms, and services. The problem is that, usually,
> each one requires that different - conflicting - sets of
> business rules be placed on the same object.

Now, I’d wager that the root problem here -- the reason that these business rules are in conflict with one another -- is because they are not business rules on a business object. He’s got presentation logic in his domain model. I might even be ok with that, as long as it is understood. However, this snippet suggests that the developer is not even aware that these so called “business rules” may, after all, be presentation logic. If I bind my business object directly to three different screens, I have these semi-independent constraints that I have to satisfy. Well, they are “rules” related to the business objects. I guess they are business rules. I’ll put them in my customer object.

I know csla does not advocate this kind of shortcut, but it REALLY facilitates this type of infraction, and is _perhaps_ in some way responsible for it. In my mental space, this is as it should be – with great power comes great responsibility and all that. From an OO standpoint, these several conflicting sets of business rules imply several distinct behaviors. An OO developer should understand that, and recognize the need for several different objects to handle these several conflicting behaviors. Should he then have several customer csla objects. No, he should have several different presenters.

So, its possible that the rule here should not be: “don’t write a presenter, since data-binding will do a better job than a thin presenter layer and its free.” Perhaps it should be “use a presenter, unless you’re damn sure that you’re screens and objects don’t need them, and remember that data binding can be used, carefully, in conjunction with presenters.” I’d imagine that if a presenter was put in front of every business object, all kinds of “business rules” would suddenly transform themselves into “presentation logic” -- even, possibly, the toUpper on all IDs :).

Anyway, thanks for reading my comments, and responding. Its been fun for me, and, as always, educational.

jsmith - You interpreted my comment fairly well with this comment: "If I bind my business object directly to three different screens, I have these semi-independent constraints that I have to satisfy. Well, they are 'rules' related to the business objects. I guess they are business rules. I'll put them in my customer object." But you missed the boat in your thinking that the rules are only presentation logic.

I do _not_ have presentation logic in my business layer, at least not in the example I had in mind when I wrote my response. <grin> The problem is the context in which the object is used. I'll use a very simple example.

Take a Contact, for example. Say the definition of a Contact is an object that holds someone's name, address, phone numbers, fax, employer's name, job title, etc. In the context of Sales Leads, the Contact's phone numbers are absolutely required. In the context of shipping, the address is required. The owner of the application says that Sales people and the shipping department must both be allowed to add Contacts. You see the problem right away. Sales people are not interested in, nor do they have the address. The Shipping department is not interested in, nor do they have, the phone number. Obviously, you cannot design the base Contact object to require either. Thus you run into the choices I outlined.

Are these UI rules? No, these are absolutely business rules. In my case, I would create separate SalesContact:Contact and Shipping:Contact objects to handle these rules. This way I can use only one form to handle the maintenance each. But I'm certainly not required to do so.

It is this type of scenario I was talking about. It happens on a regular basis to every business application developer. Of course, this is a very simple example. Generally what happens is that objects evolve over time so that the problem becomes much more difficult to see clearly. It takes a good deal of dedication and time on the part of the development team to avoid these issues.

Mark
I'm sorry. I thought the problem was one business object attached to three different "screens" -- which seems like a ui problem to me. However, now I see that you were concerned with several different business objects with a common base class -- a domain problem. I took "screen" as literally a WinForm. What you were talking about was more like a use case. My mistake.

No, jsmith, you had it right. I _wanted_ to use the same business object on three screens. It's just that my example didn't go that far... And yes, it does _seem_ like a UI problem, but the fact is that conflicting business rules can apply to the same object because of the context in which it is being used. My answer to this is usually to create a different business object that inherits from the base. What I generally end up with is a "rules" layer in my architecture; which can get pretty wide for some objects. I hope this helps in understanding my point. But even creating objects this way, some rules can get duplicated quite easily. What's a developer to do? You want to do things "right," but you want to keep getting projects, too. As you pointed out, there's a balance between keeping development costs down and building a totally OO system.

I've always had the opinion that OO - for most business applications - just doesn't fit. No matter how hard I try, I nearly always end up with a mix of OO and precedural code; if for no other reason that it just makes more sense.

We do what we can. I find that I tend to under-use objects and over-use inheritance. I think its an unconscious attempt to minimize lines of code, and perhaps a slavish devotion to a bad interpretation of the Don't Repeat Yourself principle. So I end up with an essentially procedural line of execution in my applications, and my code gets procedural. As far as I can see, there is no way out without allowing objects (and classes) to proliferate, but this takes a different mind set, and oo patterns/tricks like inversion of control hide the lines of execution, making it difficult to follow the application logic. (Following application logic is probably a procedural mindset). If someone like, say, Martin Fowler, was to sit down with smalltalk, and I sat down with visual studio, each to solve the same problem, the solutions would be radically different. There is no doubt that Fowler's application would be better than mine. On the other hand, if I try to imitate Fowler, the software I write might be truely awful. Perhaps it is not the business application, but me, the business application developer, that is a misfit for writing pure oo apps.