Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Custom Business Objects vs. Data Binding

Does anyone have any real-world experience developing non-trivial .Net Windows Forms apps using either custom business objects or data binding? Any lessons learned to share? Pros? Cons?

Specifically, a co-worker and I are in the beginning stages of a windows forms application. We have 16 years or so of experience between the two us covering enterprise VB6 apps, J2EE web apps, traditional ASP and some ASP.Net. But very little .Net Windows Forms development experience. Our background has always involved trying to approach solutions from an object oriented approach. Our enterprise VB6 started back in '98 pushes the limits of VB6 OO and our several years of J2EE experience furthered our belief in entity objects, managers, collections of objects, etc.

We have a few reference windows forms apps and they all seem to use the databinding approach (TaskVision, Infragistics Tracker, Janus' Northwind sample). In contrast to those, the ASP.Net apps I use as reference (ASP.Net Forums 2.0, DotNetNuke) lean towards a more custom business object aproach over data binding. They are actually in heavy development and are being used actively and heavily.

We will be interacting with several 3rd party components (Infragistics, Janus) that rely heavily on data binding. Our first path took us down creating our own custom business objects but we ran into issues of getting DataRowView functionality working. We are in the process of switching to the DataAdapter/DataSet approach but we just recently ran across some articles about implementing IBindingList and IEditableObject on custom objects.

We are very close to giving in to data binding but we wonder if we might not find ourselves in trouble down the road by not having objects that we can enforce business rules, etc.

All thoughts and enlightened discussions are welcome.

Matt

Matt
Tuesday, April 20, 2004

Matt,

You may like to read this page,
http://msdn.microsoft.com/library/en-us/dnbda/html/BOAGag.asp?frame=true , if you have not seen it already.

I've worked in Delphi for quite a few years.  In the Delphi world, a dataset-based approach is common.  (Even for multi-tier systems, where it is similar to passing datasets via .NET remoting).  This approach can work very well, particularly on multi-tier projects since they enforce separation between data read, write and update (server side) and display (client side).

John Rusk
Tuesday, April 20, 2004

At the moment I'm working on an app databinding directly to Business Objects, and no problems so far.

IMHO, FWIW, DataSets are evil, but YMMV! If your app is small and simple, and time is of the essence, may be the best solution.

This link may well interest you (Discussion titled "Databinding to a business object"):

http://www.dotnet247.com/247reference/msgs/41/208503.aspx

Dave Hallett
Wednesday, April 21, 2004

I think Dave hit the key point here:  how simple is the logic for your app?  If the business domain is small, business objects might be overkill. 

But end users always want another version with more features, which bring new logic and validation requirements.  If this is a long term product, investing the time to build business objects now will save you in the long run.

Joe Paradise
Wednesday, April 21, 2004

Thanks for the input. I had not run across those links before. The links that I did have before posting are:
- Roadmap for Windows Forms Data Binding ( http://support.microsoft.com/default.aspx?scid=kb;en-us;313482 )
- Complex Data Binding - Custom Implementation ( http://dotnet247.com/247reference/msgs/46/234023.aspx )

After posting I did some more research and ran across Windows Forms Data Binding and Objects ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet02252003.asp ) by Rockford Lhotka. This article really addresses exactly what we were struggling with.

A little more research turned up the author's site ( http://www.lhotka.net ) and two books that he has written: VB.Net Business Objects (June 2003)  and C# Business Objects (May 2004 - not released yet). He has put together a framework (Component-based Scalable Logical Architecture (CSLA) for .NET) to work with business objects and binding and all sorts of cool stuff. Implementing the framework might be overkill since it addresses client, web, web services, etc. but it does serve as a great reference.

As far as Dave and Joe's comments about scope and longetivty, we are definitely looking at a fairly complex app that would have a long lifetime involving lots of evolution through customer feedback.

Thanks for replying and if anyone else runs across this and has specific experience one way or the other, please share.

Regards,
Matt

Matt
Wednesday, April 21, 2004

Matt,

CSLA is just what I'm using at the moment, and I like it very much. You need to both read the book and then spend time at the MSN board to get the most from it, but I think it's well worth a look. If you have any questions about it, feel free to mail me through my sig below.

Dave Hallett
Thursday, April 22, 2004

*  Recent Topics

*  Fog Creek Home