views:

811

answers:

8

I look around and see some great snippets of code for defining rules, validation, business objects (entities) and the like, but I have to admit to having never seen a great and well-written business layer in its entirety.

I'm left knowing what I don't like, but not knowing what a great one is.

Can anyone point out some good OO business layers (or great business objects) or let me know how they judge a business layer and what makes one great?

Thanks

+2  A: 

Martin Fowler has blogged extensively about DSLs. I would recommend starting there.

http://martinfowler.com/bliki/dsl.html

Kozyarchuk
Very interesting. Thanks for the link
nlaq
I'm sorry, but Fowler's advise is lame... so theoretical and esoteric that it has lost its applicability.
dacracot
I have to agree with dacracot here. Fowler's overrated.
Draemon
+5  A: 

I imagine this is because business logic, as a general rule, is arbitrary and nasty. Garbage in, garbage out.

Also, most of the really good business layers are most probably proprietary. ;-)

Edward Z. Yang
I have to agree. Does anyone know of any good, non-proprietary examples?
objektivs
+1. I know at least two good examples, but cannot give out the sources as I'm under NDA.
Milan Babuškov
A: 

Neither have I. We don't create a business layer in our applications. Instead we use MVC-ARS. The business logic is embedded in the (S) state machine and the (A) action.

dacracot
Can you describe this a little more?
objektivs
We implement 2 layers, one is the web server and second is the database server. Each follows the MVC pattern. Within the database however, that pattern is called ARS to keep the vocabulary straight. The Representation is very much the View and the StateMachine is very much the Contoller, but...
dacracot
... they diverge for Model and Action. Model equals Representation between servers. Action is more easily understood as the SQL that transacts the data. Controller in the web server is much more of a router, pushing actions to other components. Clear as mud?
dacracot
+10  A: 

I’ve never encountered a well written business layer.

Here is Alex Papadimoulis's take on this:

[...] If you think about it, virtually every line of code in a software application is business logic:

  • The Customers database table, with its CustomerNumber (CHAR-13), ApprovedDate (DATETIME), and SalesRepName (VARCHAR-35) columns: business logic. If it wasn’t, it’d just be Table032 with Column01, Column02, and Column03.
  • The subroutine that extends a ten-percent discount to first time customers: definitely business logic. And hopefully, not soft-coded.
  • And the code that highlights past-due invoices in red: that’s business logic, too. Internet Explorer certainly doesn’t look for the strings “unpaid” and “30+ days” and go, hey, that sure would look good with a #990000 background!

So how then is possible to encapsulate all of this business logic in a single layer of code? With terrible architecture and bad code of course!

[...] By implying that a system’s architecture should include a layer dedicated to business logic, many developers employ all sorts of horribly clever techniques to achieve that goal. And it always ends up in a disaster.

Alex B
To be honest, if it took several business layers to achieve something I think that could still make for an elegant approach. There could, and ideally would, be consistency between these layers that would allow this to be considered a good layer.
objektivs
A: 

Possibly because in reality we are never able to fully decouple the business logic from the "process", the inputs, outputs, interface and that ultimately people find it hard to deal with the abstract let alone relating it back to reality.

Draemon
+2  A: 

It was helpful to me to learn and play with CSLA.Net (if you are a MS guy). I've never implemented a "pure" CSLA application, but have used many of the ideas presented in the architecture.

Your best bet is keep looking for that elusive magic bullet and use the ideas that best fit the problem you are solving. Keep it simple.

JasonS
+4  A: 

Good business layers have been designed after a thorough domain analysis. If you can capture the business' semantics and isolate it from any kind of implementation, whether that be in data storage or any specific application (including presentation), then the logic should be well-factored and reusable in different contexts.

Just as a good database schema design should capture business semantics and isolate itself from any application, a business layer should do the same and even if a database schema and a business layer describe the same entities and concepts, the two should be usable in separate contexts--a database schema shouldn't have to change even when the business logic changes unless the schema doesn't reflect the current business. A business layer should work with any storage schema provided that it's abstracted via an intermdiate layer. For example, the ADO.NET Entity framework lets you design a conceptual schema which maps to the business layer and has a separate mapping to the storage schema which can be changed without recompiling the business object layer or conceptual layer.

If a person from the business side of things can look at code written with the business layer and have a rough idea of what's going on then it might be a good indication that the objects were designed right--you've succesfully conveyed a solution in the problem domain without obfuscating it with artifacts from the solution domain.

Mark Cidade
I have started reading up on Domain Driven Design and the approach of creating entities that mean something seems to be pretty key; I think it is called "ubiquitous fluency". The idea seems sound, but I'm unsure of the implementation.Great response, thanks.
objektivs
+1  A: 

One problem I find is that even when you have a nicely designed business layer it is hard to stop business logic leaking out, and development tools tend to encourage this. For example as soon as you add a validator control to an ASP.NET WebForm you have let business logic leak out into the view. The validation should occur in the business layer and only the results of it displayed in the view. And as soon as you add constraints to a database you then have business logic in your database as well. DBA types tend to disagree strongly with this last point though.

Craig