why use business objects?

October 27, 2005 6:06 AM

From a technical point of view, why use business objects during development?

I understand the everyday reasons behind separating business logic from presentation logic. I even agree, for the most part. But technically, you're creating more work for yourself creating business objects, and it's often just as convoluted in the presentation layer dealing with your business objects as it would be dealing directly with the data. So, don't give me reasons involving OO, or making multi-development projects easier, or the same "it's a good idea because...." stuff I get everywhere. Give me hard reasons, or justify why it's a good idea to separate the presentation and business layers.

posted by taumeson to technology (27 comments total)

I would imagine that maintenance of your project is easier when the components are cleanly separated. For example, you could muck around with the presentation layer, while leaving the business layer untouched. Your testing efforts after such a change would probably be less involved then if your business logic was mixed in with all your presentation logic. If you have a clean interface for your business components, then in theory they should function as you would expect after any change in the presentation layer.

Also, you could have people developing both components separately.

I think there are probably lots of reasonably good reasons to separate the two, assuming your project is going to be around for a while.
posted by chunking express at 6:12 AM on October 27, 2005

On the project we are working on, we have both a Windows version and a web version of the main application, and they are both able to use the same business logic objects. We also have various support processes (nightly jobs, utility screens, etc) that also use those same objects.
posted by CMcKinnon at 6:15 AM on October 27, 2005

OK, these are good reasons, certainly...especially CMK's reason.

I guess I'm wondering about performance benefits or costs, or perhaps development costs for developing a robust business object layer along with a presenation layer.
posted by taumeson at 6:29 AM on October 27, 2005

There are numerous counter-examples illustrating why it's not a good idea to glom your business logic into the presentation code. We're doing a rewrite of some functionality now that uses a new presentation layer, and we're committed to using business objects. As we write the business objects, we're finding business rules scattered all over the place (we were a little slipshod the first time around). Determining what the business requirements are in an underdocumented and underspecified system is proving to be a challenge.

Also: unless/until we rewrite the old functionality to use the new business objects, we've got the same logic in multiple places. If the business logic changes, we have to remember to change it in multiple places.

The other thing to consider is the orthogonality of presentation and business logic. If the business logic changes, you don't want to have to search through twiddly bits of presentation code to determine what you have to change, and the same applies for changes to the presentation logic.
posted by flipper at 6:32 AM on October 27, 2005

Reusability and maintainence... they're not the most exciting reasons in the world, but it does make developing large projects a lot easier.

Let me give you a concrete example -- one of the apps I work on is a customer database. I have a function in the db which returns the customer's current status on a number of issues. This information was initially used on the main customer information page. Later, the boss wanted a report that included information about customer status.

Given that I'd written the function in a sufficiently abstract manner, I was just able to drop the object into place.

If something changed about the way we determined customer status, then I only have to fix it in one place and wouldn't have to worry about all the other reports and whatnot which displayed that information.

At first, it seems like more work... but really, it's just a matter of getting used to the style and building up a personal library of tricks. Not every project warrants fullblown OO behavior, of course... but for larger works, it is really, really nice.
posted by ph00dz at 6:35 AM on October 27, 2005

if it's a lot more work you're not using the right tools or you're doing something wrong. business and presentation are completely different things - there's very little overlap - so the "work" is mainly deciding what to put where. you're not duplicating anything by separating things.

the only real place i see where they tend to become mixed is in verification/error handling. that's where a good toolkit comes into its own and provides the support to keep those things separate. i use spring, for example, and that is explicitly designed to let you put verification in the business layer, report errors in the presentation layer, and still not duplicate any work.

so i question your basic premise. i'd say that you're not creating work for yourself. the business code has to go somewhere - you can put it in the presentation layer or the business layer. either way the work has to be done. and choosing to mix different things together when it's no extra work to keep them apart seems to be what really needs justification.
posted by andrew cooke at 6:37 AM on October 27, 2005

Performance is very language/domain specific. We'd need more information to address that. I can tell you that for most applications the performance difference between a MVC implementation and a all-in-one is very, very small.

Why do you believe there are greater development costs to a robust business layer? You have to implement the same requirements regardless of the object model. You're still going to have to send the same data to the presentation layer. About the only difference is that you have to give some thought to your API.

I can tell you from personal experience that it all sounds like bunk until you have practical experience. Go ahead and implement the system as you see fit. The first time you have a bug, or have to implement a new feature, the benefits of MVC/testing/shared code will probably become apparent.
posted by srburns at 6:43 AM on October 27, 2005

Just to reiterate what some of the posters have said, there is certainly more initial effort involved in developing a system with a business logic tier. The payoff comes later when you have to fix a bug, or extend the functionality to meet new requirements. Then you only have to deal with a small segment of the code base as opposed to looking through x number of web pages for code that does the same thing.
posted by smcniven at 6:56 AM on October 27, 2005

Also: unless/until we rewrite the old functionality to use the new business objects, we've got the same logic in multiple places.

But I would say that if you have decent OO design skills (again, from a technical point of view) then your reuse of logic is very minimal.

The other thing to consider is the orthogonality of presentation and business logic. If the business logic changes, you don't want to have to search through twiddly bits of presentation code to determine what you have to change, and the same applies for changes to the presentation logic.

Conversely the majority of changes to underlying data requires a change to both the business and presentation layers. Those changes are greater then if you have some of the logic together.

Another thing I'm having a hard time justifying is the wasteful use of the database. A robust business object will pull in way more data than you need, and one of the major bottlenecks in today's enterprise environments is the database.
posted by taumeson at 7:02 AM on October 27, 2005

Division of duties. While I'm seldom on a team large enough to take full advantage of it, dividing development into three tiers allows specialization. You can have a HTML/JavaScript person with minimal coding knowledge but great design skills, a middle tier person who understands the business logic and does most of the heavy lifting, and a data modeling expert to play with the back end and determine how you're going to set up caching and persistence. It's a pain if methods are constantly changing when a project is poorly defined since the interfaces between tiers will change, but when your project is mapped out everything works very smoothly.
posted by mikeh at 7:03 AM on October 27, 2005

The only justification we have are counter-examples, like Flipper said.
posted by taumeson at 7:04 AM on October 27, 2005

I forgot the other part: division of duties can be useful for security, especially in the post- Sarbannes-Oxley world we're stuck in.
posted by mikeh at 7:04 AM on October 27, 2005

I'm going to post this again to reiterate:

Another thing I'm having a hard time justifying is the wasteful use of the database. A robust business object will pull in way more data than you need, and one of the major bottlenecks in today's enterprise environments is the database.

So I have a customer object, and it has all the fields in the customer table...but say none of the pieces in my presentation layer need all of the data at the same time. If I'm going to modify my business object to reflect the needs of the presentation layer, well it kind of defeats the purpose. But if I leave the business object generic, then I'm being wasteful and there's going to be a performance hit.
posted by taumeson at 7:24 AM on October 27, 2005

then refactor your business layer so that it provides progressive access to the data. if there's a (real, justified, measured) problem with your business layer then fix it. surely that's the logical thing to do, rather than use that as an excuse to produve some godawful mess in the presentation layer.

(and people who make arguments about efficiency that involve just constant factors are, in my experience, hunting for excuses).
posted by andrew cooke at 7:37 AM on October 27, 2005

What if you have business rules that are used in more than one place in the application? Separating them out makes them consistent across all the presentation that uses them.

What is the impact of changes to optimize the use of the database? If only the business logic accesses the database, optimization changes will have a more localized impact and be easier to make without breaking anything.

The classic management way to approach this problem is to try to quantify where the time and money actually get lost. First, get the users to prioritize what they might want for a future version. Then tell them that Release 1 will cost x weeks more if you build it with the right architecture for their future wish list. If they want Release 1 x weeks sooner, you can do it with presentation and business logic mixed together. But in that case, they'll have to wait 2*x weeks after the first version for bug fixing and refactoring before any new features can be added for Release 2.

If your release cycles can be short enough, it sometimes makes sense to get something simple in front of the users as soon as possible, figure out what they really want, and then refactor out the business logic and do it right. If your release cycles are longer, you'll need to invest more in the architecture up front. Otherwise, you run the risk of not being able to do anything soon enough after the first release to change things if the users aren't happy or the business changes its mind about what it wants.
posted by fuzz at 8:17 AM on October 27, 2005

One of the biggest advantages to clean separation of concerns is testability. If your domain objects rely on your presentation layer, you will find it difficult, if not impossible, to unit test your business rules.
posted by feloniousmonk at 8:19 AM on October 27, 2005

(and people who make arguments about efficiency that involve just constant factors are, in my experience, hunting for excuses)

ah, so you've never worked directly with your users before? i'm being cheeky, but the number one complaint of everything i've ever worked on (regardless of whether or not it was my design) was that it wasn't fast enough.
posted by taumeson at 8:33 AM on October 27, 2005

As a software QA engineer, I concur wholeheartedly with the positive reasons given above for a multi-tier application architecture--for me, of course, testability is the big issue.

As for performance concerns, you're right, taumeson. Every application I've ever worked on went through a phase where performance was our big pain. In fact, we're in that phase right now in my current company. In one case, we had just the problem you described.

Our application has organizations (company name, ID, and a buttload of other info). We have an organization picker that just needs the name and ID of each organization. Every time this picker came up, we loaded the full objects for every org. It was butt slow. (User expectations for a popup picker like this was that it should be pretty much instantaneous)

In this case, we compromised on principle and created a new method (in the business level) that just queried this minimum data for each object. But again, this compromise code is reused in many places where we just need that basic info about organizations. The list of orgs with just names (and IDs of course) appears in many places in our app.
posted by tippiedog at 8:53 AM on October 27, 2005

But again, this compromise code is reused in many places where we just need that basic info about organizations.

I was about to mention this very thing! I don't think I've seen very many things that could as "compromise" code since anything worth doing once seems to get called multiple times anyway. If something is noticeably slow, then fix it! You'll probably end up writing several similar methods in the business layer eventually, but by that point you can regroup by deprecating a handful and making one more generalized method. It's better to see the business layer as a mutable blob that fits multiple needs and remains flexible.
posted by mikeh at 9:02 AM on October 27, 2005

With a well designed and speced business layer, the UI development can begin earlier, knowing that certain interfaces are going to be used. Also, since the UI is seperated from the business logic, two different developers can work on the different modules without file conflicts, which can erode a programmers productivity.
posted by jon_kill at 9:02 AM on October 27, 2005

What everyone else said, but also: Memory, processors and disk space are cheap. Software developers are many times more expensive.

If there's the slightest chance that the business logic will be extended or reused, it's a very bad decision not to componentize. Even if you might take a performance hit (which with good design is by no means a given), from a business viewpoint it's still a good investment.

Business objects save companies lots of money (developer time) in refactoring, maintenance, testing, extending, enhancing, in all but the simplest and unchanging systems.
posted by normy at 10:30 AM on October 27, 2005

What they said. As you attempt to maintain and add features to code with mixed presentation and business logic, its fragility will drive you nuts. You will resist making changes to the code because you have no idea what side effects they will have. You'll want to chuck it and start over with them separated. And you will never, ever be given the time to do that.

Been there, done that. (Being there, doing that.)

One more thing... with a well-separated template-based presentation layer in the web world, for instance, you have the possibility of turning the templates over to HTML/CSS design specialists, which you couldn't if it was all embedded in random places throughout your code. (OK, so I've never worked anywhere that was willing to actually spring for this, but I can dream of someday not having to squeeze in my own single-buttocked web design on top of everything else.)
posted by Zed_Lopez at 12:48 PM on October 27, 2005

Answers can probably also be found on this company's website.
posted by of strange foe at 1:19 PM on October 27, 2005

Answers can probably also be found on this company's website.

thanks for the link, but we're talking more about theoretical "business objects" rather than Business Objects
posted by taumeson at 1:51 PM on October 27, 2005

Building on Andrew's point that you have to implement business logic somewhere, I think separate layers actually make it easier to profile and then fix performance problems. My experience in enterprise systems is that non-hardware performance problems lurk in:

- inefficient disk or network access
- crummy SQL. (really a special case of first point)
- poor choice of algorithm in a critical, often-used piece of code
- refetching objects that can be shown not to change
- blocking when you could be doing something

None of these are going to go away if your mix up your business logic with presentation logic, but they will be harder to find, and take longer to fix.

Your example of the customer object with all the fields in it is to me an example of object - relation impedance mismatch. And again, Andrew is right; fix your model. Maybe you need to fetch fields lazily, or maybe you need a customer-summary object, or whatever.

Remember all the arguments in the HTML world about separating content and presentation? Fundamentally the same issue.

but the number one complaint of everything i've ever worked on (regardless of whether or not it was my design) was that it wasn't fast enough.

Then the problem is that somebody didn't capture performance standards when gathering requirements, or that someone didn't design to those standards, or that users have changed their mind about what is acceptable.

And I tell you what - I'm working on an old, crusty system that started out well factored and has since been thoroughly hacked on. In numerous places, business logic is mixed in with presentation code. And it's fucking nightmare, because there's cut and paste all over, or at best tightly coupled calls to subroutines that shouldn't know about globals but do. When a business rule changes, instead of changing it in one place, I have to pray that I have identified all the places it occurs and tidied everything up. Any gain in dev time or performance has been many, many times over in maintenance costs, errors, and downtime.

tippiedog's story is one I have experienced many times myself, complete with the "picker" example.
posted by i_am_joe's_spleen at 4:21 PM on October 27, 2005

Or to put that more succinctly, once you have factored you code well for efficient maintenance and enhancement, you will find that you have separate business objects.
posted by i_am_joe's_spleen at 4:35 PM on October 27, 2005

It really depends entirely on the project and the development team. If you have a small team, limited budget, and limited time, write code as quickly and efficiently as possible. If you have more people, time, or budget, and you will be involved in maintaining it for a longer period of time (or it will reflect on your career) then use as much modularity as possible.

on preview, what everyone else has said.
posted by b1tr0t at 11:03 PM on October 27, 2005