The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Business Layer Design - need opinions/your tips


I'm about to do my product's business and data layer design. As usual - the Business layer design and the CRUD layering is as painful as it always is. I'm thinking of an approach like this:

Let's say, hypothetically, I have Customer, Order and User business entities. Each needs to be filled by executing database queries. Instead of having business entities like

Customer.GetCustomerByID( id );

I was thinking of a single Business layer - for e.g., say

Customer c = Business.GetCustomerByID( id );

Orders[] o = Business.GetOrdersByCustomerID( custID );
Order o = Business.GetOrderByID( orderID);

etc. etc. The nice thing about this is, a intellisense completion of Business. will tell us all the API available in the business layer.

Now, the business API "knows" which queries to execute and fill the business object.

For e.g.

public Customer GetCustomerByID( id ) {
 string query = Resources.Queries.GetCustomerByID;
 //paramArray constructed from parameters
 DataTable dt = DataLayer.GetData(query, paramArray);
 Customer c = Customer.Fill(dt);

With this, we have one Business.cs file that
-provides all API for other app layers to use
-"knows" which queries to execute for an API and which business entity to fill
-Keep the business objects separate from knowing anything about the data layer or it's queries
-Using query names as resource values helps in ability to change queries, if required, without touching code.

I've written some code that connects to database and creates some standard queries and business objects automatically.

What do you think of this approach? how would you do it/have done it?
Wednesday, December 21, 2005
I use a similar approach in that I have a Facade out front to manage the interaction between the application and the business.  No business objects are creatable outside of this facade.

What I do differently, though, is instead of providing queries that work on an object by object basis or class by class basis, my queries work on a scenario by scenario basis.  So, for example, if I had a case where I was given a user ID and needed to access all the orders for that ID and all the line items for those orders, the query would return all of that stuff in one shot, saving a lot of round trips to the DB and allowing the application programmers to work at the (hopefully) appropriate level of abstraction.  Seems to work pretty well for my purposes.
Wednesday, December 21, 2005
If your business object knows what query to execute, why not put the query in the business object?  Don't fall for that Data Layer hogwash.

From your code example, I guess you're using .NET.  If so, check out the CSLA.NET framework.

The CSLA does all you ask and more, leaving you to focus on adding business value to your business objects.
Edward James Send private email
Wednesday, December 21, 2005
"If your business object knows what query to execute, why not put the query in the business object?  Don't fall for that Data Layer hogwash."

That is a key distinction.  Since you're using CRUD, I assume you're constructing the tables and the fields in the database to be somewhat implementation independent; it doesn't matter if the database software is Oracle or SQL Server.

The queries themselves become part of the business layer - they define the controls on the input, and mangle the output into reports.  The idea is that you can export/import stuff out of Oracle into SQL Server and (somewhat ideally) leave all the queries and processing logic alone.

In that vein, a business object is useful, but not necessary.  Most of the time, you will want to do as much processing in the query itself - for example, "return all customers that regularly paid their bills on time, up until a year ago, at which point they stopped paying."  In that scenario, you don't necessary want to fetch the customer id of everyone that paid, then turn it around and feed it back down in a second query.
Anonymous Coward
Wednesday, December 21, 2005
This is why in Java things like JDO and Hibernate exist. I'm sure things like that exist in NET.

Now, if you'll excuse me, my eyes are still bleeding from looking at your proposed API...
Thursday, December 22, 2005
Alex Tretyakov
Sunday, December 25, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz