>>This particular feature in the framework does not really break nTier development because it does not bypass the business object and it doesn't really require extra coding. The check is simply accomplished by setting three properties for a control. After that the framework performs the check automatically. It is simply a fat client duplicating logic that should be part of the business rules. The benefit is that you only code the business rule in one place and the interface takes advantage of built in functionality.
>
>Your response is somewhat different from Kevin's. By the way, I work in Codebook shop that went awry because a lot of developers polluted their
>bizobj's with UI stuff and vice versa. Turns out now the application is just not scalable, so it is being completely rewritten. The lUnique feature is perfect example of how this could happen.

I remember when I first bought the original "Codebook" book. What really confused me was that, as far as I could tell, they were preaching n-tier design but all the examples mixed the UI w/the business logic. Talk about screwing with your mind ;-)

I don't have a problem w/duplicated logic or functionality in the UI, as long as there is corresponding code in the bizobj. For example, a "Must Key" field. I'd feel comfortable with using the built-in UI property to enforce this as long as I also had a business rule for it. But, I guess it's a slippery slope - developers can get lazy and "forget" to add a rule for this in the bizobj because it's so much easier to just switch that flag.