Tech Off Thread

32 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Data Binding Business Objects

Back to Forum: Tech Off
  • User profile image
    Andrew Davey

    Quick show of hands:
    Who is data binding business (domain model) objects directly to their Windows Forms UI? (maybe BindingSource in .NET 2.0)

    Do you feel a little left out compared to the people using DataSets? For example: no built-in support for sorting and filtering in DataGrid?

    I'm going to put together a video of my BindingListView library tomorrow. I was wondering if people had some specific gripes I can show and fix using my library.

    EDIT
    Video now online: http://blw.sourceforge.net/demo.html

  • User profile image
    TommyCarlier

    I don't use strongly-typed business objects. I like the power and ease-of-use of DataTables.

  • User profile image
    JohnAskew

    I derive from BindingList<T> and prefer my own business objects over DataSets, DataTables, etc.

    I was recently asked about the expense of iterating through a DataTable.DataRows to fill a custom collection.
    I shrugged my shoulders.

    For me, having my business entity classes to work with inside my application is a much greater asset than avoiding loading them into a collection. Recordsets for UI display are a small enough number, imho.

    Of course, you won't see translations of DataRows to Business objects in the MSDN roadshow demos, where everything is written with "no lines of code". Bah.

  • User profile image
    TommyCarlier

    Well, in my code you also won't see translations of DataRows to business objects. And the applications I write for my company work like this:

    • WinForms client sends request to ASP.NET web service
    • Web service selects data from SQL Server using a DataReader, serializes the data to a compact text format
    • Web service compresses and encrypts the data, and sends it to the client
    • Client decrypts and decompresses the data, and fills a DataTable, bound to a (Xceed) GridControl.

    This whole process goes very fast, even for large amounts of data (we have forms where a grid is displayed with 30 columns and tens of thousands of rows). The DataTable is not slow at all. Actually, for large amounts of data, the slowest part in the whole process is not the server side, not the downloading to the client, not the filling of the DataTable, but the GridControl: profiling has shown me that during that process, most time is spent creating grid-row and grid-cell objects.

  • User profile image
    Tensor

    JohnAskew wrote:
    I derive from BindingList<T> and prefer my own business objects over DataSets, DataTables, etc.

    I was recently asked about the expense of iterating through a DataTable.DataRows to fill a custom collection.
    I shrugged my shoulders.



    Thats why I like datareaders!

  • User profile image
    Sven Groot

    Tensor wrote:
    
    JohnAskew wrote: I derive from BindingList<T> and prefer my own business objects over DataSets, DataTables, etc.

    I was recently asked about the expense of iterating through a DataTable.DataRows to fill a custom collection.
    I shrugged my shoulders.



    Thats why I like datareaders!

    Yep I use custom business objects, put them in a List<T>, and do so by using a DataReader. I rarely ever use DataSet/Table/whatever.

  • User profile image
    Andrew Davey

    I'm converting the screencast to a WMV as I type... I'll get it online ASAP.

    EDIT: Ergh.. Windows Media encoding looks rubbish (set on High CBR apparently) everything looks stretched and wierd even though I recorded and saved at 800x600. The raw camtasia file is crystal clear however... I'll try the SWF render instead.

  • User profile image
    Andrew Davey
  • User profile image
    TommyCarlier

    You know what a DataTable offers me that business objects usually don't have?

    1. History. A DataTable records the modifications I make. For each record, I can see if it is a newly added record, a modified record, even deleted records are not really deleted. For the modified records, I can access the original value and the current value of each field. I can reject changes. I have an easy way of sending only the modified data back to the server.

    2. Validation error management. During validation, I can easily assign errors to each field, which can be displayed to the user.

    3. All the possible DataBinding features (sorting, filtering, ...). DataTable (and its companion DataView) were (very efficiently) designed for this. So, why not use them for it?

    4. Automatic change notification. Events are raised for each change you do, without you having to explicitely implement it yourself.

    5. All fields are automatically nullable. Of course, in .NET 2.0 you now also have nullable structs, but I've been using DataTables for a long time now, and in .NET 1.1 we didn't have them.

    P.S. Andrew, cool screen cast!

  • User profile image
    Lee_Dale

    I have created a generic collection class that implements from BindingList<T> that will store any of my entity objects and fully supports binding to the UI and uses reflection to handle to ORM. Although it was alot of effort to get right i would never use DataSets again. I will reuse this collection along with my data access layer with every application i build for the .Net framework.

    TommyCarlier wrote:
    

    You know what a DataTable offers me that business objects usually don't have?

    1. History. A DataTable records the modifications I make. For each record, I can see if it is a newly added record, a modified record, even deleted records are not really deleted. For the modified records, I can access the original value and the current value of each field. I can reject changes. I have an easy way of sending only the modified data back to the server.



    I have implemented this functionality in my collection by storing clones of my collections within the collection and when you handle the ListChanged event you can access if the data was added, changed, deleted etc.  And this is gonna be more effiecient that DataSets IMO

    TommyCarlier wrote:
    

    2. Validation error management. During validation, I can easily assign errors to each field, which can be displayed to the user.



    If your entity objects implement the IDataErrorInfo interface then this helps you fully support displaying errors to the user and the error validation is more customizable that DataSets.

    TommyCarlier wrote:
    

    3. All the possible DataBinding features (sorting, filtering, ...). DataTable (and its companion DataView) were (very efficiently) designed for this. So, why not use them for it?



    I have implement sorting and filtering of my collection not sure how it compares to DataView probably not as good but im yet to optimise it and again it's fully customizable.

    TommyCarlier wrote:
    

    4. Automatic change notification. Events are raised for each change you do, without you having to explicitely implement it yourself.



    Again this can be implmented by subscribing to the ListChanged event.

     

  • User profile image
    TommyCarlier

    You're absolutely right: you CAN implement it all yourself. But my point is, why implement it all yourself? I've looked at how DataTable and DataView are implemented, and I must admit it's very tightly designed. The applications our company develops are pretty big, and there are a lot of 'business objects'. DataTables offer great flexibility and are very easy to use. They can represent single business objects, or even JOINS between business objects. We have 'business objects' with sometimes hundreds of fields, and in most Forms, we don't need all of those fields. You can decide at runtime which columns should be present. In a client/server application, the (WinForms) client can dynamically load the definition for a DataTable from the server, and you can change this on the server, without recompiling and updating the client-software.

  • User profile image
    Tensor

    TommyCarlier wrote:
     1. History. A DataTable records the modifications I make. For each record, I can see if it is a newly added record, a modified record, even deleted records are not really deleted. For the modified records, I can access the original value and the current value of each field. I can reject changes. I have an easy way of sending only the modified data back to the server.

    2. Validation error management. During validation, I can easily assign errors to each field, which can be displayed to the user.



    Check out Rocky Lhotkas Businss Objects books. They enable n-level undo for all business objects, all buried in the base classes with no need to worry about implemnetation for the business developer. It also hasa good simple field-level rule system which plays perfectyl with error providers etc.



    TommyCarlier wrote:
    
    3. All the possible DataBinding features (sorting, filtering, ...). DataTable (and its companion DataView) were (very efficiently) designed for this. So, why not use them for it?


    As above - with the slight problem on filtering. I actually did al ot of work to make filtering work on business collections, btu the filter was an object graph rather than a string that resembled a WHERE clause. I did start of down that route as well but it is none-trivial to parse a WHERE like clause, and i didnt have the time in the end.

    TommyCarlier wrote:
    
    4. Automatic change notification. Events are raised for each change you do, without you having to explicitely implement it yourself.


    Again, with the right plumbing in base classes that is trvial.

    TommyCarlier wrote:
    
    5. All fields are automatically nullable. Of course, in .NET 2.0 you now also have nullable structs, but I've been using DataTables for a long time now, and in .NET 1.1 we didn't have them.


    NULL is the devils work! Wink Of course its usefull for some stuff (usually allways dates I find) but generaly i avoid nulls unless I absolutley have to have them.


    TommyCarlier wrote:
    P.S. Andrew, cool screen cast!



    Plan to watch em tonight Smiley

  • User profile image
    Andrew Davey

    I use Rocky Lhotka's CSLA.NET business objects library. I actually code-gen most of the boiler plate property and data access code. (Using my own hybrid XSLT templating system.) The beauty of code-gen is that I can easily modify the way all the object behave in one place. For example, adding security permission checks to properties.
    Then I use partial classes to add additional methods and properties.

    My main issue with DataSet is that whilst it offers an excellent RAD experience for quick-n-dirty CRUD, I soon bang my head against its limitations. The result is lots of hacks to work around them.

    The Visual Studio Form designer is not actually dependent on specific features of System.Data.DataSet. It uses interfaces from the System.ComponentModel namespace. So any correctly designed business object can be level with a DataSet at design time. Of course a base like CSLA with code generation is the best way to be efficient here.

  • User profile image
    TommyCarlier

    Tensor, NULL is very useful. Especially in databinding scenarios. A numeric field bound to a TextBox is NULL if the TextBox is empty. But, you're kinda right, because NULL doesn't represent a value, but rather a state. It represents the absence of a value.

  • User profile image
    jmbledsoe

    I'm glad there are still some folks out there that like the DataSet model for business objects.  I think you're absolutely right, Tommy, that the DataSet model gives you all of these things for free, and while you certainly could implement them on your own, why reinvent the wheel.

    Big Smile  Yay for DataSets!  Big Smile

  • User profile image
    Andrew Davey

    Does Microsoft have a best practice documentation about when to use DataSets or custom objects? Some kind of feature matrix perhaps?

  • User profile image
    TommyCarlier

    I don't use DataSets. I use loose DataTables. In a different thread, I also explained I don't like ORM. Why does everything have to be statically typed? I've tried different approaches, including generated code and statically typed business objects. But I've always come back to using DataTables.

  • User profile image
    Lee_Dale

    TommyCarlier wrote:
    You're absolutely right: you CAN implement it all yourself. But my point is, why implement it all yourself? I've looked at how DataTable and DataView are implemented, and I must admit it's very tightly designed. The applications our company develops are pretty big, and there are a lot of 'business objects'. DataTables offer great flexibility and are very easy to use. They can represent single business objects, or even JOINS between business objects. We have 'business objects' with sometimes hundreds of fields, and in most Forms, we don't need all of those fields. You can decide at runtime which columns should be present. In a client/server application, the (WinForms) client can dynamically load the definition for a DataTable from the server, and you can change this on the server, without recompiling and updating the client-software.


    Why implement business objects instead of datasets?

    well for one Datasets contain alot of information i dont need, not being tied down to dataset/datatable semantics, and the main reason i did it was so i could completely abstract the UI and business layer away from knowing anything about ado.net. My UI knows absolutely NOTHING about where it gets it data from and is still totally bindable. I hated having to create a strongly typed dataset for every type of object i wanted to store.

    I just found my way far less proprietry and my layers much much more loosely coupled with each other so it allows me to reuse my code in many types of projects which I have found invaluable.

    I know there are way of doing it with datasets etc but trust me ive done both ways and custom collections made much more sense to me.

    I wish it was easier to do though, even with artcles from MSDN it took me alot of trial and error to get right!

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.