Data Binding Business Objects

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.

 

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!

TommyCarlier wrote:



Leeappdalecom, I'm not talking about DataSets, I don't use those either. I use DataTables in the same way you use custom collections: as a SINGLE list where each element contains fields.

I also hate creating strongly typed DataSets for every type of object. I hate the large amount of code it generates.

By using DataTable (and DataView) dynamically, I don't have to create (or generate) a class for each object type. No Person, no Project, no Invoice, no UserAccount, just DataTable.

public class Person
{
   int fID;
   public int ID
   {
      get { return fID; }
      set { fID = value; }
   }

   string fFirstName;
   public string FirstName
   {
      get { return fFirstName; }
      set { fFirstName = value; }
   }

   string fLastName;
   public string LastName
   {
      get { return fLastName; }
      set { fLastName = value; }
   }
}
BindingList<Person> lPeople = new BindingList<Person>();

The previous code snippet is just a simple example. Here is how you can create a DataTable that represents the same business object:

DataTable lPeople = new DataTable();
lPeople.Columns.Add("ID", typeof(int));
lPeople.Columns.Add("FirstName", typeof(string));
lPeople.Columns.Add("LastName", typeof(string));

Let's just agree that both approaches have advantages and disadvantages, and different people will be more comfortable with different approaches.

Don't get me wrong im not saying your way is wrong or anything, if it works for you then great, just saying how i do things and why i think it works for me. The only 2 things i personally wouldnt like about you way is first no strongly typed object (whether good or bad i like strongly typed objects), also with object classes you have the ability to put in your own validation within property accessors also lastly your UI layer would be bound to always using ado.net (again whether good or bad I personally strive to keep my layers as loosely coupled as possible and dont like tying my UI layer or businness to any one data access method).

Anyway there are so many ways to do data access and ORM everyone is going to be different it's all about learning from past experiences, I know im never gonna get it 100% right.

Andrew Davey wrote:



leeappdalecom wrote:  ... your UI layer would be bound to always using ado.net ...

Data binding in Windows Forms uses interfaces from System.ComponentModel. ADO.NET classes like DataSet and DataView happen to implement them and thus work with data binding. So the UI layer is not really bound to using ADO.NET. You could actually create a custom object that implemented the same interfaces and still data bind in exactly the same way.

Yep that's exactly what i do my collections inherit from BindingList<T>