Datasets or Business Objects?

[TwistedNerve]

Just want to see how many of you guys use datasets or custom business objects in your application. I can't decide which one I want to use yet. Any thoughts would be great!

[be58d2003]

Just want to see how many of you guys use datasets or custom business objects in your application. I can't decide which one I want to use yet. Any thoughts would be great!

Hmmm.... I am still relatively new to the programming scene, but I know what a Dataset is... but what is a business object? Isn't that like a fax machine or a copier or something? :D

 

Seriously what is a business object? :confused:

[PlausiblyDamp]

I would nearly always (except for the most trivial applications) use custom business objects in a middle layer.

 

I would normally structure any decent sized application to contain:

Data Access Layer - this handle the DB specifics, calls the stored procs, may implement some generic DB routines and should abstract out the choice of database being used. This layer will be dealing with DataSets, DataReaders etc.

Business Layer - this layer will implement the core business logic, the objects will be populated from calls into the data access layer and ultimately all updates will also go through the DAL.

 

Any front end (web, windows or even web services) will comunicate with the business layer and take advantage of the functionalilty offered there.

[AlexCode]

be58d2003 You did get the point, on your joke, relating to objects, just forgot to convert the meaning that the word object have in a OOP language environment. In a OOP language, everything is an object.

 

Like in the office hardware, the Fax machine its an object and have it's hown 'properties' that act the way we want when we use the 'interface', in a OOP language based software the idea is quite the same.

 

So, to pack the whole idea, a 'Business Object' it's a class, or a set of classes (objects) to help you manage certain tasks, in this case, DB tasks.

 

Alex :p

[AlexCode]

TwistedNerve

 

Now I'm using a third party component from DevExpress called XPO, allways applyed on an n-tier structure.

 

As PlausiblyDamp posted, in a common n-tier implementation you have 3 layers:

Data Access (DAL) - This layer should bread by it self. No references to other projects... nothing. Another good practice is to use interfaces to define the class structures. This way you can create several DAL's for several Data Providers for instance (SQL, ORACLE, TEXT Files, XML).

 

Business Logical (BLL) - This should be the only layer allowed to comunicate with the DAL. Acting this way and using the interfaces to define the DAL structure its easy to change the database engine, you only have to change the DAL dll... the rest will work smothlly.

 

Presentation (PL) - Deals with the interface. You should build this layer in a matter that, If in the future you need to completlly renew the software interface you don't even need to recompile the application core (DAL & BLL).

 

Sometimes, in some special cases, is needed a 4th layer:

Modal (ML) - This layer is referenced by all other layers. This is where you store objects that are needed by all or more than one layer.

 

--\\--

 

As I earlly said, I'm using the XPO (Xpress Persistent Objects) from DevExpress. This set of objects act like a mixture of DAL with BLL and prevents the need to make several DAL objects for each needed data provider witch turns out to be very productive.

 

The DataSet structure it's ideal for the DAL, giving you the tool to "draw" you DB schema, enabling XML serialization... You still need to create your BLL to deal with that.

 

I hoppe I wasn't too boring... :-\

 

Alex :p

[TwistedNerve]

Thanks everyone!

 

What do u guys think about Microsoft's recommendation. They say you should have a component which houses your business entities, which is basically just a thin object exposing public attributes. Then, there is another component, let's say business services, which handles all the communication with the data access layer and performing the actual business logic. The business enties are created and populated in the data access layer and passed back up the chain to the BL. The UI also creates this business entity objects, and passes them to the business services layer. I guess I am just trying to figure out whether to go this route or just have one business component, that performs the validation and business logic.

 

Any thoughts about this?

[AlexCode]

Hi,

I explained you what are the standard layers on an n-tier environment, now I need to tell you how they interact with eachother.

 

As I said earlyer, DAL should the left alone. By alone I mean that it should reference any other project (layer).

 

The only authorized project (layer) to connect with the DAL should be BLL.

 

To end it, PL should only reference BLL and should never have any business logic in it, oly things related with the appearance of the application.

 

Example

Imagine a simple application, a Form with a DataGrid and a Button.

The button, when clicked, should fill the DataGrid with the company clients.

 

Let's use the n-tier model to create this application:

PL: Have the Form with the grid and the button.

BLL: Have a Function called GetClients that retrieves a DataTable.

DAL: Have also a Function called GetClients and also retrieves a DataTable.

 

Put it to work:

On the Button Click event call the BLL GetClients Function and set the result as the DataGrid's DataSource.

When the BLL's GetClients method is called it should call the GetClients on the DAL.

 

This example looks a little supid as you may ask what is BLL doing here???

If I called the DAL GetClients Function directly it yould work as well!!

True, and sometimes we can join some layers on the n-tier model. If the application were to stay like this, the BLL could desapear.

 

But now imagine, instead of displaying all the clients, sometime you only wanted to display a filtered set of them.

 

In this case you could add a Textbox to the PL, where you can enter the query and pass it in an Overloaded GetClients Function on the BLL.

 

In this new scenario you have a BLL with 2 overloaded functions, one that need no parameters an retrieves all the clients, and another that needs a query parameter. In this lat one you can call the very same DAL GetClients functions, retrieving them all, but after, you can use a DataView to filter the data and then retrieve it.

 

Now BLL is beginning to make some sence! :-\

 

 

 

Now for the Interface part.

I only see a use for the interfaces on the above model if you need to connect with different DataBase "sources", lets say SQL and XML.

Imagine that there can be clients using data from an SQL Server but also some other ones only using XML files.

 

As the only layer connecting to the DAL is BLL, if the methods in DAL are the same, and retrieve the same datatype there should be no problem.

Tho make sure that "the methods in DAL are the same, and retrieve the same datatype" you should create an Interface, representing all the DAL public methods. This way, when you need to add another "DataProvider" to your application you only need to create a new class, implement this Interface and fill the methods so they retrieve the apropriate data :p nice!

 

I hope this was usefull...

 

Alex

[m_oliveira]

My Business Objects

 

Hi, guys

 

My business objects layout is something like the following:

 

 

 

SQL Server DB <---> Data Retrieval Object <---> Director <---> Base Form <---> Inherited Form

...................................................|........../

...................................................|........./

...................................................|......../

...................................................|......./

.........................................Business Object

 

 

I have one Business Object for each logical entity (e.g. Customer, Invoice, Employee, etc.), and each business object in turn has one property for each column in the table. All data requests are made through stored procedures, and each business object has a standard function wich "knows" how to build a string to provide parameters for the respective insert, update, select and delete stored procedures. The Director Object receives calls from the forms and ask the correct business object for the parameter string, and then pass the parameter string back to the Data Retrieval Object. The DRO returns the dataset to the Director Object, and the latter pass the dataset to the Business Object, wich in turn fills its own properties' values.

 

Regards,

 

Marcelo Oliveira