Architecture

Re: Debate: Do We Really Need Three Layer Architecture?

LudovicoVan — Wed, 12 Nov 2008 01:16:19 GMT

Momcilo,

> Ah, angry or crazy, who knows...
> I spent last hour trying to actually write some code, but couldn't help thinking about how to help our friend Abhi

Bad bad, you should know! As for our friend Abhi, if s/he needs help, then s/he can wait, IMHO.

> For me, the most important question here is - who is responsible for this confusion?
> Developers themselves, universities, software companies not willing to invest into education?
> Or the internet where everybody is an "expert" and people get confused by "layers", "tiers" and "angry monkeys"?

So, that is your top question, and your list of candidates. Moreover, shall I be looking forward to the web form for registering as an "expert" and get the e-badge?

> "Writing software would be a lot easier if it weren't for customers"

Writing software would be a lot easier if it weren't for the vendors, for instance. Does it matter? My top question would rather have been: how to solve the given problem.

-LV

Re: Debate: Do We Really Need Three Layer Architecture?

benhart — Tue, 11 Nov 2008 23:07:20 GMT

LudovicoVan:

The quote I'd paraphrase like this:

<< In software, lots of the practices on projects exist because “that’s the way all the cool people do it.” In other words, because of crazy monkeys. >>

Perhaps I'm missing the intended humour here, but I'd paraphrase it as

<< In software, lots of the practices on projects exists because people adopt those of the people that came before them without ever questioning and (more importantly) understanding why they originally adopted them. >>

Momcilo, there are doubtless many reasons for much confusion. Our really young industry has a particularly low barrier to entry, and an extremely long path to mastery. This puts us in a fairly unique position where we are, for the most part, the partially-sighted leading the blind. Good advice has the habit of repeating though, and, even if ignored the first time, will be remembered when it's learned the hard way. Please continue to keep giving it .

Re: Debate: Do We Really Need Three Layer Architecture?

Momcilo — Tue, 11 Nov 2008 20:52:24 GMT

LudovicoVan:

Momcilo,

I couldn't agree more with your first post.

As to the second, I'm afraid not. The quote I'd paraphrase like this:

<< In software, lots of the practices on projects exist because “that’s the way all the cool people do it.” In other words, because of crazy monkeys. >>

Or so I see it.

-LV

Ah, angry or crazy, who knows... I spent last hour trying to actually write some code, but couldn't help thinking about how to help our friend Abhi: http://forums.asp.net/t/1346305.aspx

For me, the most important question here is - who is responsible for this confusion? Developers themselves, universities, software companies not willing to invest into education? Or the internet where everybody is an "expert" and people get confused by "layers", "tiers" and "angry monkeys"?

Re: Debate: Do We Really Need Three Layer Architecture?

LudovicoVan — Tue, 11 Nov 2008 20:24:19 GMT

Momcilo,

I couldn't agree more with your first post.

As to the second, I'm afraid not. The quote I'd paraphrase like this:

<< In software, lots of the practices on projects exist because “that’s the way all the cool people do it.” In other words, because of crazy monkeys. >>

Or so I see it.

-LV

Re: Debate: Do We Really Need Three Layer Architecture?

benhart — Tue, 11 Nov 2008 20:17:16 GMT

Momcilo, that's a great quote. Thanks

Re: Debate: Do We Really Need Three Layer Architecture?

Momcilo — Tue, 11 Nov 2008 19:32:53 GMT

"Back in the 1960s (when scientists were allowed to do all kinds of crazy things), behavioral
scientists conducted an experiment where they placed five monkeys in a room with a
stepladder and a bunch of bananas hanging from the ceiling. The monkeys quickly figured out
that they could climb the ladder and eat the bananas, but every time the monkeys got near
the stepladder, the scientists would douse the entire room in ice cold water. You can guess
what that generated: angry monkeys. Soon, none of the monkeys would go near the ladder.

Then, the scientists replaced one of the monkeys with a new monkey, who had not been subject
to the blasts of water. The first thing he did was make a beeline for the ladder, and all the other
monkeys beat him up. He didn’t know why they were beating him up, but he quickly learned:
don’t go near the ladder. Gradually, the scientists replaced the original monkeys with new
monkeys until they had a group of monkeys who had never been doused with cold water, yet
they would still attack any monkey that approached the ladder.

The point? In software, lots of the practices on projects exist because “that’s the way we’ve
always done it.” In other words, because of angry monkeys."

("The Productive Programmer", Neal Ford, p144)

Re: Debate: Do We Really Need Three Layer Architecture?

Momcilo — Tue, 11 Nov 2008 18:31:03 GMT

"Three Layer/Tier Architecture" is oversimplification of some very important programming principles and is widely misunderstood. Some people really write useless “proxy” classes just to call them “business layer”, but (I saw this with my own eyes) then pass SQL strings from their “presentation layer” back to “data access layer”… That is no better than procedural code, but is in fact much worse.

“Layers” evolve naturally where the complexity is. It is very hard work to identify logical units, encapsulate them properly and keep your code/classes clean and simple. It is not known in advance, it is our job to figure out while analyzing and coding. And we are always surprised by what happens.

Re: Debate: Do We Really Need Three Layer Architecture?

joycsharp — Tue, 11 Nov 2008 13:59:00 GMT

@EntitySpaces
@TATWORTH
@LudovicoVan

Agreed

Re: Debate: Do We Really Need Three Layer Architecture?

LudovicoVan — Tue, 11 Nov 2008 13:35:13 GMT

TATWORTH:

Mike Griffin >My short answer "No, you don't"

You Sir are brave to state that opinion. I agree with you. We may both be flamed.

If 3-layer fulfills a need, then fine. However, I have seen 3-layer systems that seem to be more of an exercise in in complexity, than fulfilling a genuine need.

Feel free to count me in.

Most of current architectural trends are just that, trendy over-engineering, richer vendors' catalogues, unjustified costs of development, unmanageable extra-complexity, flooding the software arena with sellable nonsense, hooligans of this or that new techno-religion, et similia.

(Call it pre-emptive counter-flaming if you like. ;)

-LV

Re: Debate: Do We Really Need Three Layer Architecture?

TATWORTH — Tue, 11 Nov 2008 11:23:13 GMT

Mike Griffin >My short answer "No, you don't"

You Sir are brave to state that opinion. I agree with you. We may both be flamed.

If 3-layer fulfills a need, then fine. However, I have seen 3-layer systems that seem to be more of an exercise in in complexity, than fulfilling a genuine need.

Re: Debate: Do We Really Need Three Layer Architecture?

EntitySpaces — Fri, 07 Nov 2008 18:48:16 GMT

My short answer "No, you don't"

This is the way we do it at EntitySpaces and hope I can contribute here a little.

1) We generate a set of classes from your database schema, we call them the generated classes.
2) We then generate (one time only) a set of custom classes that inherit from the generated classes

public class Custom : Generated
{

}

You can override almost everything in the "Generated" classes, including the properties accessors.

Your custom class is originally empty but you can add business logic to them as you see fit. The nice thing about this is your Custom class has only your code in it and none of our underlying infrastructure, so all you see is your true business logic. Also, our system is provider independent so you never use SqlClient or OracleClient and you can switch providers without even recompiling by just changing your connection string in the config. This approach makes for a very rapid development system with almost zero maintenance impact incurred by changing your database schema. Just regenerate and you're off.

The generated class is a kind of "BusinessObject/DataObject combo", however we never use the term DAL, DAL died 8 years ago or so for me, even in previous architectures. The code is simple, and 8 year old could crank out a system on it.

Employee emp = new Employee();
emp.FirstName = "Joe";
emp.LastName = "Smith";
emp.Save();

That's it, of course, we have a killer dynamic query API so you can fetch things on the fly. But in the above code you can overload Save, and the two property accessors if you needed to. There's so much more too, you can use dynamic SQL or stored procs by merely indicating so in the config file.

Overall, it's meant to allow you knock out projects quickly, and it's extremely fast performance wise, no layers, no facades, no dals, no xml, no reflection, just get er' done. Also runs on Mono, Compact Framework, and Medium Trust environments.

Mike Griffin
EntitySpaces LLC
Persistence Layer and Business Objects for Microsoft .NET
http://www.entityspaces.net

Re: Debate: Do We Really Need Three Layer Architecture?

benhart — Fri, 07 Nov 2008 07:23:18 GMT

As I've intimated, I don't have a layer (separate project or otherwise) called BLL or DAL, so I find it hard to imagine what a loosely intimate layered model might be. Is this a term that you've coined? Is it written up somewhere so I can understand better what you're referring to?

I define object shapes and behaviours centrally, and make use of an ORM to map these to a database. These entities are loaded via 'abstracted' repositories (a known interface, for which the implementation is injected to calling code via an IoC container). Thus there is very little intimacy between what I suppose is my DAL and BLL, but using those terms does lead one immediately to think of a Pet Store type architecture. (Apologies if I'm misrepresenting the Pet Store - I seem to remember it being a reference architecture I looked through some time ago, in summary central data class definitions in a common assembly, a corresponding BLL which called a corresponding DAL to load one of these entities, "pass-through" business logic.) I moved away from this for the reasons I think I mentioned, but am not knocking it per se.

A previous poster has linked to an article regarding active record vs. objects. You preference either way, and the nature of the system being developed will without doubt impact your decisions architecturally and the language you use to describe it.

In a nutshell, what's preferable to me is long term maintainability, and I'm always open to ideas that improve this...

Re: Debate: Do We Really Need Three Layer Architecture?

joycsharp — Fri, 07 Nov 2008 07:01:30 GMT

joycsharp:

Now we need to consider whether we need to consider Tight or Loose Intimacy between Layers.

For instance we have two data/business entities: School and Student, where we have some business rule included in School entity, where as vthe Student entity doesn’t have. For a “Tightly Intimate Layered” model, we may have SchoolBLL, StudentBLL at business logic layer, following which we’ll have SchoolDAL and StudentDAL at data access layer. For a “Loosely Intimate Layered” model, we’ll have SchoolBLL only in business logic layer along with SchoolDAL and StudentDAL.

benhart:
Done incorrectly you can find yourself with the same mesh of code with low cohesion and high coupling. I've seen BLL classes with nothing in them, just more coupling to instance or static calls to the corresponding dal code. This to me is the waste I referred to, you have another class implemented to follow a pattern, but which serves no purpose, and still needs to be maintained. If you have a lot of these you might wish to consider why.

So in that case, "Loosely Intimate Layered Model" is preferable?

Re: Debate: Do We Really Need Three Layer Architecture?

Chuck M. — Thu, 06 Nov 2008 20:41:08 GMT

This is a really broad question that lacks context, but here’s my 2 cents:

First, note what most consider layers and tiers: http://blogs.msdn.com/jmeier/archive/2008/09/06/layers-and-tiers.aspx, as people on this thread seem to be using the two interchangeably.

“Do We Really Need Three Layer Architecture”

Layers are just logical organization for common features, just like creating namespaces, classes, and functions. Layered architecture is very useful; the number of layers is irrelevant. The bigger problem is building the right level of abstraction to solve your problem, while accommodating readability and extensibility.

“How many of your data entities include business logic”

Are you modeling behavior or data in your code? There is a difference. Bob Martin wrote a good post on this a while back: http://blog.objectmentor.com/articles/2007/11/02/active-record-vs-objects.

“I know for sure my database vendor is not going to be changed, then why we need another layer?”

How many API’s has Microsoft created for SQL Server over the years? Vendors might not change much, but it is important to abstract persistence API’s, as they change a lot and it’s low level detail that doesn’t need to be spread throughout your codebase. If I’m reading code that validates and saves data, I want to read a high level abstraction, not what query is called or what SQL data types are being used.

Re: Debate: Do We Really Need Three Layer Architecture?

chadmyers — Wed, 05 Nov 2008 23:49:18 GMT

As with any architectural optional, the choice must be well considered and should be seriously scrutinized. So let's scrutinize the n-tier architecture model...

What is the motivation of the layered (I would argue that what you're calling 'layers' are actually 'tiers', but I digress) architecture?

What do you gain by this approach?

How easy will it be to reverse this decision in the future?

How easy will it be to test this approach?

How easy will it be to maintain and add new features going forward?

Will this architecture scale up or out? What effect will that have on the infrastructure supporting this decision?

There's a million other questions to ask, but so far, these are good questions to start with.

For me, reversibility is key. No architecture survives first contact with developers. There is no amount of planning up front that will account for every situation. So the architecture plan must account for sweeping changes and reversal of failures and bad assumptions.

From my experience, trying to achieve a stratospheric approach (having hard tiering between 'data' and 'business logic', and 'ui'), reversibility suffers significantly and a lot of optimization and effort goes into each tier, but not into the whole system which ultimately suffers because of it.

A more holistic approach might be in order that allows logic to exist where it's most appropriate, but stay consistent with respect to the entire system might be a better approach.