ObservableCollection

rfcdejong posted on Thursday, October 22, 2009

With the comming of CSLA 4.0

I suppose some windows people will not be happy, but i really hope CSLA will drop the BindingList and replace it for ObservableCollection. Fully support WPF or at least with the use of conditionals.

Fintanv replied on Thursday, October 22, 2009

rxelizondo replied on Thursday, October 22, 2009

ajj3085 replied on Thursday, October 22, 2009

Of course people are free to say you could rip out whatever you consider bloat.

As much as I would love to rewrite my application in Wpf, its not really a choice I have, and so I must continue with WinForms.

rxelizondo replied on Thursday, October 22, 2009

ajj3085:

Of course people are free to say you could rip out whatever you consider bloat.

As much as I would love to rewrite my application in Wpf, its not really a choice I have, and so I must continue with WinForms.

RockfordLhotka replied on Thursday, October 22, 2009

This thread already has two different topics...

The ObservableCollection vs BindingList issue is a big one, and I spun up a thread months ago to solicit input. The problem is that a lot of people need to migrate from Windows Forms to WPF and can't just do it in one big bang.

If I drop BindingList, I drop Windows Forms. Pure and simple. Which would mean people using Windows Forms (or doing migration over time) would be unable to move to CSLA .NET 4.0. They could probably run 3.8 on .NET 4.0, but they couldn't upgrade to newer versions of CSLA .NET until the eliminate all use of Windows Forms.

I would prefer to find a way to allow Windows Forms to function in CSLA .NET 4.0, but I absolutely intend for the collection base classes to switch to ObservableCollection. In my mind that is an absolute requirement for version 4.0.

The backward compat (bloat) issue is a different matter. The reason is that I'll bet you good money that there's no agreement about which "legacy features" to cut.

Just a couple weeks ago I suggested dropping per-instance business rules and got vehement disagreement. And that's for a very little-used feature.

But what if I generally cut support for private backing fields? To me that's legacy - but I bet most people still use them.

One thing I really might do is rework business/validation rules to have more consistent naming, and for business rules to have a different delegate signature - not really cutting out any bloat, but incurring wide-spread breaking change to improve future clarity.

In one sense you are absolutely correct - a major version change (like 3.x to 4.x) is an opportunity to make some breaking changes. I've managed to preserve backward compat from 2.1 through 3.8 (to a high degree), and 4.0 will almost certainly include a relatively high number of breaking changes.

At the same time, there are people still to this day trapped on 1.5.3 because the number of breaking changes between 1.5.3 and 2.1 is too big a hurdle. The fewer people I can trap on pre-4.0 versions the better.

rxelizondo replied on Thursday, October 22, 2009

Rocky,

Regarding “bloat” and “legacy code”: You know that people will *ALWAYS* resist change no matter what and if you are going to wait for all of us to agree in something then you might as well forget about it.

However I will give you my humble opinion. The CSLA has reached a point were its size and complexity has increased to a point where anyone trying to get a good understanding of the framework has to spend *significant* amount of time studding it…. and I am not kidding about the *significant* amount of time.

I work for a big company in the US and I can tell you that selling the CSLA for new projects is extremely difficult (most times impossible) because people see the 10000 classes on it and all that code and are completely turned off by it. For all practical purposes the CSLA could be closed source and it wouldn’t make a difference because very few people know the CSLA good enough to dare make changes to it anymore.

So here is my advice to you:

1. Start fresh every time a new .Net version comes up (including this 4.0), say not to backwards compatibility period.
2. Let contributors enhance and fix previous versions of the CSLA. Anyone that has a vested interest on keeping the old version alive could participate.
3. Split the CSLA in to two dlls, one to hold the core CSLA essentials (this will be covered in the book) and the other the peripheral utilities or non essentials such as WinForms, LINQ to CSLA etc (this could be cover in some e-book). This will keep the CSLA simple and friendly.
4. Do not bloat the framework with stuff like the C5 libraries unless is extremely necessary or if used for the peripheral utilities dll.

The key here is to bring the CSLA back to the all people and not just the privileged ones that have all that time necessary to study all that material. To remove the added complexity of figuring out what is no longer applicable and what is (“legacy code”) and to remove some fragilities on the framework introduced due to backwards compatibility needs.

Take a chance and go for it, cold feet never got anyone anywhere. Don’t let the CSLA be a framework lemming.

Based on my experience, very few people actively make changes to project such as upgrading the CSLA, 95% of the time a project gets created and remains that way. Unless its a major undertaking and if that is the case, its better to update to a compact and readable framework rather than a bloated one. No one likes bloat (legacy code).

RockfordLhotka replied on Thursday, October 22, 2009

I think the idea that people modify open source code (of any real magnitude) is a general myth. I once had a guy argue that they needed to use MySQL instead of SQL Server because they might need to modify the database engine.

How many people in the world are actually qualified to modify database engine code? And why would someone who could do something like that be working in a regular IT shop? That's just crazy.

6-7 years ago CSLA .NET was an example of a framework more than an actual framework. And people modified it because it was a skeleton, not a complete thing. Starting in 2005 though, I think it became a real thing, and I've been treating it as such for the past 4-5 years.

To that end, I've added a lot of "bloat" in the form of extensibility points and flexibility. All so that people (advanced to be sure) could alter the behavior of key aspects of the framework without altering the framework itself.

There's a lot of complexity introduced by all the virtual methods, provider plugins, indirection services and so forth. Eliminating all of them would radically simplify CSLA .NET - and would ensure that almost everyone had to modify the framework to actually use it.

In 3.5, anticipating Silverlight's reflection issues, I added the whole new managed backing field concept. And in 3.6, anticipating some future version of ADO.NET EF that may or may not happen, I added the ObjectFactory concept.

Arguably then, private backing fields and DataPortal_XYZ methods are bloat. As are per-instance business/validation/authz rules.

Looking into the very near future, I think support for Windows Forms and Web Forms are bloat, as is any support for asmx. And you could argue that the whole channel adapter functionality and support for Enterprise Services are bloat.

And I think the LINQ to CSLA implementation (at least LinqBindingList) was a mistake and that there's a better, though more intrusive, solution to that problem. And I think the L2C indexing feature might be better handled by an external library like i4o. This, btw, would eliminate the need for C5.

Don't get me wrong - I do think eliminating some of these things must be done. The framework can't continue to grow at the rate of Microsoft change - because their rate of change is increasing and my bandwidth is constant.

At the same time, there are thousands of people around the world using CSLA .NET, and I think it only right that I feel some responsibility for providing a level of consistency and a way to migrate for the user community.

One of the primary features of CSLA .NET, in my mind, is that it helps protect your investment in your business layer. Not the UI - that's disposable. Not the data access - that's disposable. But the business layer, where you capture and codify the logic of your business domain - now that's valuable IP that should be preserved as much as possible over time.

In other words, dropping Windows Forms isn't entirely out of the question because that's UI - expendable. Radically rearranging the way business classes are constructed must be avoided, because that violates the primary purpose of CSLA .NET.

Of course you could (and I may) make the argument that 3.5 introduced managed backing fields 3 years ago. By the time I release 4.0 people will have had nearly 4 years to migrate from private to managed backing fields.

(If you haven't guessed, I'm of two minds on this debate - the side of change, and the side of stability - only time will tell which one wins out)

JonnyBee replied on Friday, October 23, 2009

• intermediate baseclasses
• how to extend/modify Csla behaviour without tinkering inside Csla. Like:
  
• ValidationRules
• List classes
  
• Templates and snippets
• Custom UI controls/extenders
  
• Solution structure (UI/BO/Factories)
• Sync vs Async methods (DataPortal)
  

RockfordLhotka replied on Friday, October 23, 2009

Wbmstrmjb replied on Monday, October 26, 2009

RockfordLhotka:

You are right though, I should write an Extending CSLA .NET
ebook or something…

ajj3085 replied on Friday, October 23, 2009

JonnyBee:

I've stepped into most of these pitfalls until I created my own set of intermediate baseclasses and moved my "small" changes out of Csla. If we all used intermediate baseclasses and put our additions into a separate assembly it would be a really small change to move to/from different types of baseclasses (ObservableCollection/BindingList) without changes in the BusinessObjects. And it would also make it easier to upgrade to newer versions of Csla.

There is stilla few areas where we need to use private backing fields, such as NotUndoable and NonSerializable, that the framework could handle better.

.And even if Rocky decides to drop WindowsForms and WebForms we could keep the baseclasses in a community effort (as it is complete) and let Rocky focus on the new stuff.

What have you moved out that allowed you to easily switch between BindingList<T> and ObservableCollection?  My understanding of the problem was that WinForms expects behaviors implemented by BindingList<T>, and WPF expects ObservableCollection, and so changing the base class of BusinessListBase to ovserablecollection would break WinForms applications.

ajj3085 replied on Friday, October 23, 2009

RockfordLhotka:

In other words, dropping Windows Forms isn't entirely out of the question because that's UI - expendable. Radically rearranging the way business classes are constructed must be avoided, because that violates the primary purpose of CSLA .NET.

Well given that, isn't the whole problem that WinForms likes BindingList<T> while WPF / Silverlight would rather ObservableCollection?  What happens in a few years when Wpf is replaced by a new UI and we get another collection base to use?

Something seems wrong if the motivation to switch the ultimate superclass for BusinessListBase from one class to another is driven by the UI of the day.  

RockfordLhotka replied on Friday, October 23, 2009

ajj3085 replied on Friday, October 23, 2009

RockfordLhotka:

I surely agree with this statement!

 The problem is that I’ve wracked my brain for a real solution to this, and I don’t see one. Microsoft keeps inventing UI binding technologies that rely on behaviors from the objects. 

While we can create a “view object” over a collection, that turns out to be very problematic if you have an object hierarchy – because it means you need to intercept all binding attempts and replace the real list with a view object – and that complicates the UI code rather a lot – and sometimes isn’t even possible (with treeview or more powerful datagrid controls that bind to a whole object graph). 

In other words, I can elegantly solve the simple case – binding the UI to a 1-level list of objects. But I don’t see an elegant solution to a parent-child-grandchild case…

You would think that it should be possible to make both happy; are grids going after BindingList<T>, or the IBindlingList interface?  Is Wpf going after ObserableCollection<T>, or Collection + INotifyCollectionChanged + INotifyPropertyChanged?

RockfordLhotka replied on Friday, October 23, 2009

Henrik replied on Friday, October 23, 2009

rxelizondo replied on Friday, October 23, 2009

RockfordLhotka:

One of the primary features of CSLA .NET, in my mind, is that it helps protect your investment in your business layer.

But it is protected! Even if you were to start a whole new completely different version of the CSLA. Nobody forces anyone to update to a new version of the CSLA. If I build my app using the CSLA version 2.5 then I can keep that version for as long as I want without having to update anything. *That is how* my investment is protected.

How you define investment is very different from how I define investment, my definition of CSLA investment is: “out with the old, in with the new”. I **MUCH** rather update to a CSLA framework that is a mean lean machine than to a CSLA that tries to be a jack of all trades. Even if it means that I have to do a lot of rework, at the end, I know it would be worth it.

To put it in simpler words, I agree that it would be great if the battery of my 15 year cell phone could be used by my brand new cell phone, I mean, my battery investment would be protected right? But all things consider I rather pay the price for a new battery that is the size of my credit card rather than have to use an old battery that is the size of a brick.

Also, you have to understand that so much is riding on the CSLA when an application is built on top of the CSLA that it’s only natural that a company would want its engineers to master the framework before they start coding the app based on it. The in-depth understanding of the CSLA framework is what allows people to take sound architectural decisions *on the spot* with confidence and avoid possible pitfalls. Having a CSLA framework that is a mean lean machine makes it easier for developers to learn it and master it.

I must insist. I would encourage you to break the CSLA into two dlls, the core (the book) and the utilities (e-book).  Let people start learning the CSLA in 1st gear, don’t force people to start on 5th gear. Not just that, what best way to sell the CSLA than to show people how easy is to extend the core dll, you can prove that by showing them what you did with the utilities dll.

Also, as stated above, say *NO* to backwards compatibility. You and your brains are the *true* investment here. Apply you time to move the CSLA forward and don’t waste your time bending over backwards to provide and maintain backwards compatibility. Microsoft does that all the time, big deal, we have managed to survive.

RockfordLhotka replied on Friday, October 23, 2009

>I would encourage you to break the CSLA into two
>dlls, the core (the book) and the utilities (e-book). 

Sadly, this doesn't address the ObservableCollection vs BindingList issue - not in any real sense.

Ultimately I think the only answer to that problem is that in 4.0 BLB will derive from ObservableCollection, and (hopefully) there can be a Csla.Windows.BusinessListBase that derives from BindingList<T>.

I haven't done this yet, so there could be unexpected complications, but it seems like the answer.

Moving Csla.Windows.BusinessListBase into another assembly might be workable - but will almost certainly force me to make a bunch of internal things public. Anything I make public must meet a higher bar than internal types/methods, because people will (mis)use anything that's public.

So it might be most time/cost-effective to put this new (well, old) BLB in Csla.Windows, but in the same Csla.dll assembly.

Henrik replied on Friday, October 23, 2009

tmg4340 replied on Friday, October 23, 2009

rxelizondo:

But it is protected! Even if you were to start a whole new completely different version of the CSLA. Nobody forces anyone to update to a new version of the CSLA. If I build my app using the CSLA version 2.5 then I can keep that version for as long as I want without having to update anything. *That is how* my investment is protected.

rxelizondo:

Also, as stated above, say *NO* to backwards compatibility. You and your brains are the *true* investment here. Apply you time to move the CSLA forward and don’t waste your time bending over backwards to provide and maintain backwards compatibility. Microsoft does that all the time, big deal, we have managed to survive.

Microsoft doesn't break backwards compatability "all the time".  In fact, until rather recently, Microsoft bent over backwards to *maintain* backwards compatability.  Yes, doing so is what eventually got them in trouble with Windows.  And it also cost them an awful lot of money and time - things Rocky does not possess in great abundance.  The fact that he's able to do it at all is somewhat remarkable.

Also, suggesting that those who use older versions should either "put up or shut up" seems rather harsh.  Yes, there is nothing stopping you from staying in 2.5.  But what are you to do when you run into one of the issue with 2.5 that was fixed in, say, 3.5?  If I were you, I suspect my answer would be "bite the bullet and upgrade".  I don't know what your job is, but in my job (and in the job of most programmers I know), that is not a decision taken lightly, whether it's CSLA, .NET, or any other framework we may use to get our job done.  My technical issues often do not rate highly on my customers' list of needs, and my paycheck derives rather directly from my customers' list of needs.  You can say that "if they want it badly enough, they'll pay for it."  But there is another decision to be made - "we won't do that."  If those decisions are made often enough, I'm looking for another job - and standing on principle does not feed my wife or children. 

Microsoft has quite clearly put Rocky in a rock-and-hard-place situation.  I'm saying that taking the stand that you take seems, in large measure, to be an impractical one when you view it from the entire community.  To cut off a rather significant segment of his "user base" simply because they don't have the time/money/facilities/whatever to upgrade ultimately takes away a segment of CSLA users, which gives him less money/impetus to continue advancing on the framework.  It's also somewhat unfair to penalize them because of these reasons, many of which may be out of their control.

FWIW, it's been my feeling for a while that CSLA needs to branch into multiple assemblies to deal with the peculiarities of the various technologies he is supporting - WinForms, WPF, ASP.NET (in all its various forms), and Silverlight.  I've never been a huge fan of compiler directives, and they only solve a small portion of these issues anyway.  Having said that, I have a feeling for what this kind of architecture would do to the CSLA codebase, and just how much work it would likely take Rocky and his team to do this.  It's the very definition of "breaking change".  But unfortunately, I think it's come to this.

- Scott

RockfordLhotka replied on Friday, October 23, 2009

>CSLA needs to branch into multiple assemblies to
>deal with the peculiarities of the various technologies he is supporting

I sort of agree with this - but again we come back to the ultimate base class issue.

I absolutely could split out the UI widgets/helpers for web/win/wpf/wf/silverlight into separate assemblies.

But that still doesn't mean whatever core I create would work with WinForms and WPF...

And I should point out that CSLA .NET 1.x had several assemblies. The single biggest complaint I got from people at that time was that they had to reference too many assemblies to do anything. There was a resounding cheer when 2.0 came out with just one Csla.dll :)

tmg4340 replied on Friday, October 23, 2009

This is part of what I'm talking about when I mentioned the effort of splitting CSLA.  I understand the complaints about all the CSLA assemblies.  But like I said, Microsoft seems determined to drive you to that end.  So I say embrace the insanity. 

I guess what I could see are essentially five "assemblies":

1. Core CSLA for the WinForms/ASP.NET world (i.e. the "old" data-binding style)

2. Core CSLA for the WPF/Silverlight world (i.e. the "new" data-binding style)

3. The Winforms UI/widgets.

4. The ASP.NET UI/widgets.

5. The WPF/Silverlight UI/widgets (though this might have to be split as well.  While the plan is obviously to drive these two to a common base, they aren't there yet...)

Things start to get hairy when trying to feed #1 and #2 into the DataPortal, but I still think that's manageable.  Those tracks are fairly similar, and I think the adapter patterns you've set up will help here.

It may be possible to have some ultimate base assemblies to support both #1 and #2, because the binding technologies are sorta-kinda-almost common.  But I think if you're going to allow the framework to move forward, as well as allow for some kind of backwards compatability, I honestly see this as "the way out".

FWIW, I'd say this even if I had to do it.  Not that I'm necessarily volunteering - just saying that I'm not offering up the hardest solution because I don't have to figure it out. 

- Scott

rxelizondo replied on Monday, October 26, 2009

I agree with "who will maintain old versions of the CSLA" would be a sticky point when it comes to having people accept that new version of the CSLA should break backward compatibility or not. I guess that if Rocky would make some type of “official” commitment to fix major bug or any type of security issue on older version of the CSLA for a given period of time, users of the CSLA would be more willing to accept having the CSLA break backwards compatibility. Not sure Rocky would have the time do that although I would be willing to bet that fixing old versions of the CSLA would take less time that trying to figure out how to maintain backwards compatibility on new versions.

RockfordLhotka:

Sadly, this doesn't address the ObservableCollection vs BindingList issue - not in any real sense.

I wasn’t really referring to this issue. My main motivation to break the CSLA is to make it simpler. Yes, I agree that if you put everything in is own little namespace and folder that things could be a little better but you are totally ignoring the physiological factor that having all that code has on developers.

I remember back in the good old days of CSLA when a developer could go through the whole CSLA and understand every aspect of it. That’s what gave developers confidence to use the CSLA and in my opinion that is what made the CSLA grow.

Again, my motivation for breaking the CSLA into multiple assemblies and to remove backwards compatibility is to be able to bring the CSLA back to a level where the average Joe can master the core CSLA.

This will make it a lot easier to sell the CSLA for project creation because developer would be exited to build something on top that they understand or can see the light at the end of the tunnel. All that extra clutter does not help even if it can technically be ignored.

And by the way, you can complete ignore and call me names for saying this, but the fact remains that most developers biggest problem with the CSLA at this time it’s the size and complexity... atleast that has been my feeling for some time now :)

RockfordLhotka:

Moving Csla.Windows.BusinessListBase into another assembly might be workable - but will almost certainly force me to make a bunch of internal things public. Anything I make public must meet a higher bar than internal types/methods, because people will (mis)use anything that's public.

This is not good news! I almost want to say that if that is the case then something most be inherently wrong with the CSLA extensibility design….. but I won’t say that because that wouldn’t be appropriate so just ignore this sentence :)

But seriously, if this was the case maybe there is work to be done here, It think its only logical to think that when it comes down to extending the framework with functionality that is not critical to the CSLA you should be able to do this by using a different assembly and not have to insert such functionally directly it on the CSLA core assembly. But realize that the person writing that is a person that is just picking up on CSLA 3.x so my comment may be completely off the mark.

RockfordLhotka:

And I should point out that CSLA .NET 1.x had several assemblies. The single biggest complaint I got from people at that time was that they had to reference too many assemblies to do anything. There was a resounding cheer when 2.0 came out with just one Csla.dll :)

The thing is that back in the day, the CSLA was split on several dlls that were intrinsic to the operation of the CSLA. Very few people would not reference all those dlls so there was very little point on having the separated. All those dlls had nothing to do with UI stuff by the way (other than perhaps the resources dll).

Things are different now, UI stuff does not really belong on the CSLA core anymore, that stuff should be removed to make the core CSLA cleaner.

ajj3085 replied on Tuesday, October 27, 2009

I hope that it stays in one assembly.  There seems to be no benefit and a whole lot of headaches to splitting them.  The argument for the split seems to be learning... but that's what the book is for.

I like the idea of moving the current BusinessListBase... but maybe instead of moving it a new collection base of BusinessCollectionBase is called for.