CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • BusinessListBase vs BusinessBindingListBase

    Answered (Verified) This post has 1 verified answer | 27 Replies | 5 Followers

    Top 25 Contributor
    498 Posts
    Tiago Freitas Leal posted on Sun, May 30 2010 1:59 PM

    Hi all.

    Sharing some experiences and raisising a point.

    As you might have noticed, under CSLA.NET 4 BusinessListBase changed - when the collection changes, instead of raising the ListChanged event as it used to, it raises the CollectionChanged event.

    This is old news and is all on the release notes. If you want to migrate your Windows Forms projects to CSLA.NET 4 all you have to do is to use BusinessBindingListBase.

    I have this Windows Forms project and after porting (almost) everything from CSLA.NET 3.0.5 to CSLA.NEt 4.0.0 I got very weird problems using a DataGridView, like the list pointing to the wrong item, deleted rows didn't go away, etc. That was weird because there were a lot of errors and not that easy to reproduce.

    I went to my library classes and just replaced BusinessListBase with BusinessBindingListBase and Bingo! All of a sudden the project was all right!.

    Besides sharing the experience, I think this also raises a point. If we must use BusinessBindingListBase for Windows Forms and BusinessListBase for WPF/Silverlight, suppose my application has both clients. I need to have duplicated Business*ListBase classes?

    Not to mention the WPF/Silverlight issue. I can see that the sample projects (PTracker) use conditional compiler directives to keep different implementations on the same source.

    Of course we can use the same trick for the WindowsForms / WPF issue:

    #if WPF
        public partial class Folders : BusinessListBase<Folders, Folder>
    #else
        public partial class Folders : BusinessBindingListBase<Folders, Folder>
    #endif

    We can have conditional compiler directives for 3 UI environments and I'm afraid that soon enough programs risk to get unreadable. One has to find its way through the conditional compiler directives instead of browsing code. I mean we will be debuging conditional compiler directives instead of debuging code.

    Tiago Freitas Leal, CslaGenFork (Open Source CSLA code generator)

    Answered (Verified) Verified Answer

    Top 10 Contributor
    9,475 Posts

    tiago:

    Besides sharing the experience, I think this also raises a point. If we must use BusinessBindingListBase for Windows Forms and BusinessListBase for WPF/Silverlight, suppose my application has both clients. I need to have duplicated Business*ListBase classes?

    Not to mention the WPF/Silverlight issue. I can see that the sample projects (PTracker) use conditional compiler directives to keep different implementations on the same source.

    Several months ago, perhaps even a year ago, I started a thread to discuss what CSLA 4 should do about the Windows Forms vs WPF/SL app problem. There is no good answer. None.

    My first instinct was to drop Windows Forms entirely. That was rejected (with good reasons) by many people on the forum. The approach taken by CSLA 4 is (imo) the only meaningful alternative - provide a set of collection types for Windows Forms, and update the primary collection types to work with everything else.

    I have absolutely no idea how to make one list work for both Windows Forms and XAML. I do not believe it is possible, not in any realistic sense.

    When it comes to ProjectTracker - that is VERY far from being complete for CSLA 4. I have just started the process of making it work for Silverlight, which is where the compiler directives come in. That's pretty typical for any SL app - your objects will have some minor differences between SL and .NET that must be addressed. We've worked very hard to minimize those differences, but some things just can't be hidden (you can't have data access or synchronous factory code in your SL code - that just isn't possible).

    ProjectTracker does work for ASP.NET MVC, as that's been my focus with that particular project so far. That's not done either, but the functionality that is there does work. Next I'll be working on the Silverlight client, then WPF. The Windows Forms client will probably go away in ProjectTracker - or will move to a completely separate version of the sample - specifically because the collection types can't be shared between Windows Forms and the rest of the UI technologies...

    Rocky

    All Replies

    Top 10 Contributor
    9,475 Posts
    Suggested by RockfordLhotka

    This is covered quite thoroughly in the Using CSLA 4: Creating Business Objects ebook starting on page 78.

    For example, Table 16 lists every interface technology, and the base collection types (ObservableCollection or BindingList) that work with that interface technology.

     

    Rocky

    Top 200 Contributor
    49 Posts

    Hi, after reading that chapter, I don't know if I'm smart enough.

    After all, it seems to me that the only way to go is to use conditionals, similar to what you have used for SILVERLIGHT, e.g.

    #if WINFORMS

    // use BusinessBindingListBase

    #else

    // for everything other than windows forms use BusinessListBase

    #endif

    And to have two build versions of the same business classes (when targeting WinForms and the others).
    But if I see how targeting the silverlight version is recommeded it seems that for the silverlight (or WP7) I must have another build.
    But here I'm in doubts. To have same name for assemblies and organize them in subfolders or to distinguish them by name and keep in the one folder for all dependencies?

    I haven't read the whole ebook series yet. But I want to quickly ask what should I do at first? Do you recommend to create own CSLA derivate for base classes, which will be directly used in my business layers?
    But things get little bit complicated. That derivate should have the same number of CSLA derivate builds as the original one, shouldn't it? And finally my business layers should have also have also so many builds as needed by the target UI platforms.

    Please, I need clarification.
    Thanks

    Top 10 Contributor
    9,475 Posts

    That is an interesting and unusual perspective.

    I have been posting in this thread under the assumption that you have existing WinForms code, and need to migrate to WPF over time. That is the common scenario. Although a little challenging, by supporting OC and BL collections, CSLA 4 makes it possible to do this migration.

    It sounds like you are intentionally going to write a new WinForms app? And a WPF app over the same business layer?

    Why would you ever do such a thing? It is hard to imagine how you could cost-justify creating two apps that both target Windows and (presumably) provide the same functionality?

    Rocky

    Top 200 Contributor
    49 Posts

    No, you didn't understand me well.

    I'm going to build new business layer which must be used in an existing WinForms application, because this is what we have and we can provide almost instantly to customer.

    But in parallel with legacy WinForm application we want to build new applications based on WPF/Silverlight or ASP.NET or combination ASP.NET with Silverlight.

    And somewhere in the future to be cut off from the WinForms UI.

    I'm just thinking about the way how to do the both and not to fight with technologies.

    That's why I'm asking in such way.

    Thanks

    Top 10 Contributor
    9,475 Posts

    Thank you for the clarification.

    In that case, where the business layer will be used by WinForms or WPF, but never at the same time (by a hybrid app), I think your idea of using a compiler directive is probably good.

    As much as possible, we made BusinessListBase code-compatible with the old version (now called BusinessBindingListBase). For example, BLB supports the AddNewCore overload concepts from BindingList, even though that has no meaning in the OC world. Because other parts of CSLA use it, there's still value in implementing it - but more importantly, we enabled the same code to work, with just the base type being changed.

    That isn't always the case. For example, if you manually raise changed events, BLB uses OnCollectionChanged and BBLB uses OnListChanged - and there's not a lot we can do about that, because the events aren't the same.

    But most business code doesn't do fancy stuff, and so most business collection classes can switch between the BLB and BBLB base classes with very little code difference. That means the compiler directive approach should be fine.

    Rocky

    Top 200 Contributor
    49 Posts

    Hi, I've just tested if I could bind BusinessListBase to WinForms DataGridView and some other 3rd party GridControl.

    At first sight binding just works. Also I can wrap it with SortedBindingList to provide sorting in grid.

    Also I've tried BusinessBindingListBase, and found no different behavior between the two lists.

    I'm using CSLA 4.1.

    Another interesting point is that ReadOnlyListBase is able to accept adding items into it without clearing IsReadOnly flag but ReadOnlyBindingListBase doesn't.

     

    Top 10 Contributor
    9,475 Posts

    Miroslav Galajda:

    Another interesting point is that ReadOnlyListBase is able to accept adding items into it without clearing IsReadOnly flag but ReadOnlyBindingListBase doesn't.

     

    This is a perfect example that demonstrates how several features of BindingList don't exist in ObservableCollection. The whole concept of allowing edit/remove/add to a list is a BindingList feature. Because OC doesn't implement this feature, WinForms treats the collection as though all the options are true - except for add.

    In the case of add, BindingList has AddNew and OC does not. So auto-adding of an item in an OC requires that the child type have a public default constructor, and you can't override the use of that constructor (no use of data portal Create to initialize the child).

    Rocky

    Top 200 Contributor
    49 Posts

    This is what I'm looking for. What all features will not work if I bind BLB to WinForm or what features do I need to add manually.

    Because the first try I made is just working fine.

    Top 10 Contributor
    9,475 Posts

    I have not worked with WinForms for several years, and I don't remember the full list of missing features. You will have to experiment to see what doesn't work.

    Rocky

    Top 10 Contributor
    2,279 Posts
    JonnyBee replied on Thu, May 26 2011 11:03 AM

    I would expect a number of issues lurking in the shadows.

    SortedBindingList and FilteredBindingList support adding/deleting/editing rows in the underlying list. I would expect these to fail at updating the UI or  DatagridViews properly as the event they attach to is the ListChangedEvent from BindingList.

    Ex:

        public FilteredBindingList(IList<T> list)
        {
          _list = list;

          if (_list is IBindingList)
          {
            _supportsBinding = true;
            _bindingList = (IBindingList)_list;
            _bindingList.ListChanged +=
              new ListChangedEventHandler(SourceChanged);
          }

        }

     

        public SortedBindingList(IList<T> list)
        {
          _list = list;

          if (_list is IBindingList)
          {
            _supportsBinding = true;
            _bindingList = (IBindingList)_list;
            _bindingList.ListChanged +=
              new ListChangedEventHandler(SourceChanged);
          }

        }

     

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 10 Contributor
    9,475 Posts

    Starting in .NET 2.0, Microsoft worked to make some common scenarios work against non-BindingList collections. You might be able to search MSDN or blogs to find some article that describes what they did to support collections that don't actively participate in binding.

    Probably searching for "binding a collection to windows forms" will return some useful results.

    Think about it this way: Windows Forms is designed to work with BindingList collections. They did what they could to support "dumber" collection types. ObservableCollection is a "dumber" collection type (from a Windows Forms perspective), so any limits discussed in blogs and articles from 2005 apply today as well.

    Rocky

    Top 200 Contributor
    49 Posts

    OK, thank you. I will try to fight against them. :-)

    One thing I'm scared about is too complicated model of multiple builds of libraries.

    Do you recommend to create own layer (derived CSLA base classes) bon top of CSLA and use that layer as base "CSLA" layer, don't you?

    This will result into following model of libraries, won't it?

    Client\CSLADerived.dll

    Silverlight\CSLADerived.dll

    Server\CSLADerived.dll

    ...?

     

    Top 10 Contributor
    9,475 Posts

    Tiago Freitas Leal:

    Besides sharing the experience, I think this also raises a point. If we must use BusinessBindingListBase for Windows Forms and BusinessListBase for WPF/Silverlight, suppose my application has both clients. I need to have duplicated Business*ListBase classes?

    Yes, if you have one business DLL that is used by Windows Forms and WPF UI elements in the same app, then you probably have to create duplicated collection classes.

    In my observation, this normally happens when an org has a Windows Forms app, and they migrate to WPF over a period of months or years. So the same app is running some WinForms and some WPF, often using Microsoft's interop capabilities.

    My recommendation is to port logical units of functionality from WinForms to WPF, one unit at a time. This way you can port a number of forms to WPF, and can port the related business types as well.

    This won't eliminate the need for some duplicate collection types, but it can help reduce the number of duplicates.

    The real key is to minimize the number of duplicated editable list types. Read-only lists that subclass ReadOnlyListBase usually work fine in WinForms, because none of the "missing" features are used against a read-only list. Only editable lists are problematic.

    Rocky

    Page 2 of 2 (28 items) < Previous 1 2 | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems