Business Objects

[eric13]

We are moving to VB.net from Foxpro and are trying to decide on how to develop our first major .net application. I've been doing some research and have found that some dislike the use of DataSets, preferring the use of classes that use ComponentModel interfaces to bind to windows forms calling them business objects. What are your feelings on passing on the DataSet model and using a Business objects model?

 

[vis781]

Well this is just one Vis781's opinion but i like datasets. They are an integral part of the System.Data Namespace. They are versatile in that they can read and write Xml and can hold a collection of datatable objects to create a scaled down in memory relational database. Why go to the effort of re-inventing the wheel? As i say, just my opinion.

 

[Paszt]

The only Buiness objects models I've seen do use datasets. It's not a matter of replacing the dataset with other classes, it's a matter of building in a third layer to seperate the business logic from the GUI code. This is the primary principles of object-oriented design: encapsulation. Encapsulation is what allows a client (the GUI) to interact with an object without knowledge of its implementation details, thus keeping it loosly coupled.

An example of this is the DataTableAdapter used in VS.NET 2005 which is a custom, generated control that is analogous to a DataAdapter. In other words, the IDE generates the business layer for you.

I believe using the Business model Architecture is the best way to approach building a data aware app, especially if you wish to have an open architecture and an application that is fully scalable.

 

[vis781]

I assumed eric13 was talking about creating collections in custom classes. If i was right then here's about the best summary i have read to date..

Originally Posted By Someone Called Dino
Both DataSets and custom classes don't limit what you can do in any way, and both can be used to accomplish the same aims. That said, DataSets are fantastic tools for prototyping applications and represent excellent solutions for building systems in a kind of emergency—a limited budget, an approaching deadline, or a short application lifetime. For relatively simple applications, custom entities add a perhaps unnecessary level of complexity. In this case, I suggest that you seriously consider using DataSets.

In the economy of a large, durable, complex enterprise system that takes several months to complete, the cost of architecting and implementing a bunch of collections classes is relatively minimal and is incurred only once. The advantages in terms of performance, expressivity, readability, and ease of maintenance largely repay the investment. You are not bound to a tabular rendering of data. Business rules and custom business entities can't always be adapted to look like a collection of tables. In general, you should avoid adapting data to the data container—quite the reverse, I'd say. Finally, using custom classes makes for easier unit testing because classes and logic are more strictly related than with DataSets.

 

[eric13]

"creating collections in custom classes" is what I was referring to as business objects.

I guess I prefer to use stored procedures and it seems that if you retrieve data via SP with joins into a dataset that the datatables in the dataset cannot update back to your database (I may be mistaken) I'm having a hard time committing to writing my sql in my vb classes or vb front ends.

If you are committed to using stored procedures, are datasets a good option, or are custom classes a better answer.

Are BindingSource objects used when using custom classes?

If using custom classes, is setting up relations between classes a problem...example...having a datagrid1 bound to one collection of a class and datagrid2 bound to a child collection. When you you move the cursor in datagrid1, it only shows rows in datagrid2 that relate to the primary key of the datagrid1 selected row. Any examples on how to do this would be helpful.

Sorry for all the questions...just want to get this right

 

[vis781]

If you are committed to using stored procedures, are datasets a good option, or are custom classes a better answer.

Well that really is the burning question isn't it?. Lets get serious for a minute, in my opinion a dataset/datatable is a native .net framework object created by MS to generic. So lets face it they could never be ment as the be all and end all. It all depends on your requirements and the scale of your application layer. As MCSD it is part of the job to determine what is needed, 'a business solution'. At present i have never found a need to not use datasets, it's a judgement call and based on financial implications and timeframe weighed against the benefits of creating a 'business object' as described in the article i posted above. Without knowing more about your situation it would be almost impossible to advise.

Are BindingSource objects used when using custom classes?

Why not, everything is possible. Again it would depend on the factors i've outlined above

If using custom classes, is setting up relations between classes a problem...example...having a datagrid1 bound to one collection of a class and datagrid2 bound to a child collection. When you you move the cursor in datagrid1, it only shows rows in datagrid2 that relate to the primary key of the datagrid1 selected row. Any examples on how to do this would be helpful.

If you don't mind me being brutally honest, if you are asking this question you should be using a dataset. There is no way i could just come up with a brand new 'business object' that is capable of relational sorting. The .Net Framework has got it built in, so i would use them. This is just my opinion, there are many people on this forum with more knowledge than I. Hopefully they may step in and play devils advocate.

 

[TechGnome]

This is something I struggle with nearly every day..... Just like any thing else in the programming world, it really depends upon your needs and the needs of the application... if I'm displaying a number of items in a datagrid - like a list of customers - or in a combo box - like a list of states or options - then I use a dataset (or a data reader for combos most likely).... but when dealing with a single item, then I'll use a custom class and populate it with the data I need. As for relationships.... in a way they can be a part of your classes, if you design them right....

Example: in our app, we have a parent object, Customer.... below that is a Billing level where invoices are generated, below that is the Account information.

Currently each one is a separate object, linked on internal ids....
In the next version, we hope to rengineer it so that the developer can go:
[vbcode]
SomeCustomer.Billing(0).Account(0).AccountName
[/vbcode]

Meanwhile, on screens where we display lists of customers, it should be a DataTable that is simply popped into the datagrid and displayed.

-tg

 

[Paszt]

Perhaps I don't understand the concept of "business objects" or my explanation of the DataTableAdapter was misunderstood. (I do understand these "business object" but I just think the idea is obsolete when using VS2005 as partial classes allow you to customize generated data objects, among many other features).

Either way here is a series of tutorials dealing with a very good way to handle working with data: Building and using a 3-tiered data architecture with ASP.NET 2.0
Although the article focuses on ASP.NET, the concepts can be applied to winforms. The Data Access Layer tutorial is must read for people just starting with data access in .NET V2.