I beg to differ on this opinion. I feel that architecture plays a very direct role in the happiness of the customer. May I make a stretch of an analogy to illustrate:

I choose a hotel because of their feature list: 5 stars, room service and 9 elevators. The place is beautiful (hey, it's a 5-star place!). It feels warm and cozy, it's clean and the staff are exceedingly friendly and helpful. However... the architects cut a few corners when they built the place. It turns out that there are 9 1-floor elevators to get from floor to floor. They all look and run real nice, but they aren't a very practical way of moving about. The so-called "room service" turns out to be someone at the concierge desk running across the street to the food market. Nice features, poor implementation.

My point is that underlying architecture can have a significant impact on the behavior and performance of an application, and thus user hapiness. True, the architecture itself might not be visible to the end user, but it certainly affects their experience when you are dealing with the right applications. An application that provides flexible implementation and/or option add-ons because it can handle it architecturally is significantly more attractive.

Like Imar says, if you are building one-off applications, the complexity of an OO purist design may very likely make no sense. You can implement something much faster with a simpler design. You just have to accept the risk of it.

-Peter

Certainly. Many of my business classes rely on other business classes to perform their logic. This is an important point when you are keeping your layers separate. I've run across instances where I'm writing some data logic and realized that I needed to call business logic. Because my BLL reference the DAL, I can't do that without a circular reference. This tells me that I'm actually doing something that is business logic not data logic (such as combining data structures into logical business structures). It can get tricky where you should make the distinction.

-Peter

Peter,

May be I was not clear in making those statments. I agree with you that Architecture is key to success of a valuable product. And as you said Architecture will influence various aspects of the application.

What I meant is that without a good architecture the application will suffer from various issues which means that customers are not getting good value from the application. So in a way customer satisfaction is directly related to a good architecture. However, what I also meant is that it is upto the developer to worry about the aspects of architecture and liase with customers. Customers may not know about N-Tier design or Factory Pattern etc. So basically we both are saying same thing but may be in a different way :)

Regarding interaction between layers, how I work is that I do not allow DAL's to communicate with each other and I am sure you would be doing same (as this is why we have BLL). What I do to be more flexible is to have another layer called Business Processes which is responsible to orchestrate things. e.g. if for a certain operation I need 5 BLL's then I create a process that call these rather than BLL1 calling BLL2 etc. This way BO-BLL-DAL set becomes flexible and combinely cohesive.

Tahir

If you put code that calls the BLLs in another layer called BusinessProcesses, then what exactly is in the BLL classes? I guess I don't see what the difference is or should be between the two. I put my business processes in the BLL. I don't see what the point to having 2 business logic/process layers.

-Peter

Business Processs can be in BLL but I dont consider a process and logic same. e.g.

In one of the application I am working on, I have made TaxBLL and NIBLL, each having logic specific to calculating Tax and NIC. However in running of payroll we will require to use both Tax and NIC BLL's. For this I created RunPayrollProcess which calls various BLL's like TaxBLL, NIBLL... RunPayrollProcess is a class which is a business process rather than business logic.

A process can be called business logic and can be in BLL however creating a seperate layer makes the application more flexible in my opinion.

Having said this, one can have RunPayrollBLL which does the same job. I opt to use XXXProcess as the convention for clearity.

Tahir

Peter/Imar,

In my previous post I explained what I consider is the difference bwtween business process layer and logic layer. How would you design similar scenarios?

Tahir

Tahir,

You have described how you distinguish between process and logic. Frankly, I don't see any difference. In my view, a "process" is a business concept. We as programmers then implement those processes in a body of logic in code. The bigger idea we are looking at is really the idea of separation of an application's layers. Whether you want to break on particular layer's logic into many layers/libraries/classes or not is up to you. At that point it becomes a personal/organization preference or standard.

I have not encountered situations where that level of granular separation is required. I suppose that in most cases, so many area's of business logic/process depend on so many others that it becomes very difficult to keep them all in different "layers" due their interdependence.

-Peter

Tahir,

I assume that what you are referring to here and on my web site is known as the "Model VIew Controller" pattern, right?

http://en.wikipedia.org/wiki/Model-view-controller

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
Want to be my colleague? Then check out this post.

Hi,

Well Business Process and Logic are almost same and is a matter of choice.

There is an even more important discussion that I would like to have. I read the book by Rockford and it made me think about this architecture if BO, BLL and DAL. I have read the forum on his website and his discussions and views on SOA. He calls SOA another name for procedural way.

When I mentioned in the beginning of this discussion that I think of this as SOA and not OOA because Object do not encapsulate data and behavior, and Peter questioned that what rule says that an object should have both data AND behavior. Afte reading those forums by Rockford I believe that I was somewhat write in thinking this as SOA.

What do you people think about this. Is this not a Procedural architecture?

Another related question: The BO are dumb classes with get/set. Where is the validation code placed in such a design? Is it in BO's set method or in a BLL's method (e.g. Validate).

Tahir

The answer is: it all depends.

There is no black and white, there is no right or wrong, there is no true or false, there is no good or evil, there is no yin and yang and there is no spoon.

There is, however, Kruder and Dorfmeister, Bonnie & Clyde, Black & Decker, Jesus and Mary Chain, Kim Gordon and Thurston Moore and Oil & Vinegar but that's a different story.

You ask questions like "Where is the validation code placed in such a design?" and the answer is: "it depends on where you put them."

For example, in my article about n-layer design, I put them in the Bll and make the Bll responsible for validating the BO.

In Lhotka's design, where the layers are much more packed together, you find parts of it in the property setters and getters, and part of it in other parts.

If you don't trust the BO and BLL developers, you may have to repeat parts of the validation in the DAL as well.

I am not sure if this is still a discussion. You ask questions, but you don't offer much back. You're not offering your view on things as a basis for discussion, but you just want to know "What do you people think about this" and make us put a label on it.

My answer, and what I think of it, is: "it depends".

On Monday I make other decisions than on Wednesday night. I make other decisions when I am sober than when I am drunk. Ten minutes before a dead-line I make other decisions than when researching for an article. When I get paid $20,000 to come up with a wicked design for a framework on top of a CRM system I make other decisions than when I design a $2,000 web site.

So, it all depends.....

I am out of this discussion for a while. Have a real-world dead-line to make.....

Imar
---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results and Beginning Dreamweaver MX / MX 2004
While typing this post, I was listening to: Radical Adults Lick Godhead Style by Sonic Youth (Track 5 from the album: Murray Street) What's This?