Many assumptions made

I offer this as constructive critisism

I thought that this article was not a good one at all.
In fact, it demonstrates the confusion that many have and the author is no exception in this case.

Firstly the title and the content sometimes offers no relation to each other. Considering the title - Boosting your .NET Application Performance and the content that is inside. ie. The choice of content for representing the title is not a very good one.

The author starts by discussing n-tier architecture, and in the first [Note] section categorically states that "[Note] tier and layer mean the same thing [End Note]"

This is is indeed not the case and the author shuld be careful not to use them as the same thing.

The author continues by stating that there are usually three tiers and confuses the BLL and DAL into one tier stating that these are called sub layers. - raises many questions?

By the authors definition it seems as if he thinks that a Physical layer is both logical and physical at the same time, and that a logical layer is divided into "sets of classes" - do you mean components? Could you answer the following question by the definition - Can a layer be comprised of many components and if so what if two components that made 1 logical layer was to appear on two physical layers? (using your definitions in the question).

The author states - "Please DO note that separating the layers physically WILL slow your application down due to the delay in communicating between the servers throughout the network, so if you are using the physical layer approach, make sure the performance gain is worth the performance loss from this."

- Is the author really saying that a web server farm will be slower than 1 server dealing with 100 000 concurrent clients? It is not good to assume and to make the reader believe that a physical seperation is always a slower option.

The author states - "You might also want a separate SQL server if you have other applications using the same data. "
You have opened a can of worms here. should you not have stated more about issues surrounding this kind of decision?


The next note section reads - "[Note] You should develop an application bottom up. This means build the data tier layer first. You should always design all three layers before building the actual application. [End Note] "

By the Authors definition of Data tier, (which I do not particularly agree with), he states that this must be the first thing you do. In many cases you would not want to design a database first. I know that it is normal practice but there are fundamental problems with this approach. The Author cannot state that this should be done as a rule.

The author then mentions performance, scalability, and future developments. the author states - "When deciding on your architecture, decide what your priority is going to be. If your application is time critical, then you might have to sacrifice its scalability and extendibility just because you need more procedural like class design, which will offer that. "

Firstly why do I have to sacrifice scalability for time? It is not difficult to design a relatively scalable system. Also what has procedural class design mean? Do you mean stateless objects? In which case, stateless objects are best for Service layers nad was previously recommended practice. The author is suggesting that "procedural like class design" is not scalable. This is not true.

Further the author states that scalability comes from "scaling out"
This is definitely not true. Some have developed websites that handle 25 000 concurrent users offering good performance, while others battle at handling 20 users. Why is this? is it not true that if one then improved the code to handle 25 000 from 20 that they needn't not necessarily throw hardware at it?

The author states - "Architecture is a topic that really doesn't have best practices so rather than going for architecture for all of your applications, think about different architecture for each of your applications. "

Wow - this is one that really gets me going. How can the author state that there are really no good practices? Is it because he is not aware of any? What about Frameworks who are the enforcers of good architecture. How could one design and implement a framework if there were no good practices. And how could one design a good framework if they never used Design Patterns? And how could one design a scalable or extensible or adaptable system without these good practices? Furthermore is the author not contradicting himself with firstly stating that tiers, layers, logical or physical are all good practices and then stating that there are really none at all?

The rest of the document is also spiked with all sorts of problems.

take the phraze referring to IBuySpy
"If you are designing a Content Management System or something of the like, then this is the best way to do it. "
Has the author ever designed a content management System that was larger than IBuySpy in code?

---

I will leave it there. My critisism in a nutshell is as follows:
The author should take greater care in the future to not confuse readers who utimately look up to authors to know their subject really really well. The author does not know his subject well. My intention is none other than to point out some of the incredible jumps and factors that I find in articles all the time and this one contained more assumptions and bad elements than I have seen in a long time.

Jonathan

Jonathan Crossland
Author
System Component Architect
Yokogawa Marex

Jonathan,
On some points I agree with you, and on some I don't -- I guess that particular article is open to interpretation, as many will agree.

If you'd like to discuss the article with James, then send him an email at james@devarticles.com. I'm sure he will be more than happy to disuss particular points of the article with you.

Jamon,

Thank you for your criticism. Ill try to look out for the points you have made for my next article.

But let me explain some of things you have mentioned.

It seems to me you have missed the point of the article. IMO, using the terminology, following best practices (all the time as you have said) and other things you have mentioned are less important than you having the ability to know different ways that are available, and knowing what factors should affect your decision in using one of the ways that are available. And also the different naming of the tiers and layers are not important to me. I really don't care if 4 layers are called 1st, 2nd 3rd 4th layer.. as long as the readers understand an application can be built not as 1 unit but in alot of "components" and set of classes.



I think i was clear enough in saying that the logical layers are in one physical machine where as physical layers are hosted in different machines. All i said was

"Firstly, a logical layer means that layers are separate in terms of assembly or sets of classes, but are still hosted on the same server. Physical layer means that those assemblies or sets of classes are hosted on different servers "

Where did u get the idea that physical layer is both logical and physical?



You've missed out the next sentence
"so if you are using the physical layer approach, make sure the performance gain is worth the performance loss from this. " Meaning the performance loss from the network communication, shuld be made up by the perf gain made from the physical distributed architecture.



The definition Data-Tier is from MSDN. Data Tier refers to the data source. XML, SQL Server etc. I never said it must be the first thing you do. I said you should. Also note I said near the end

"think about different architecture for each of your applications. " This means the developer reading this should think about things i said and see if it applies to their applications. Not follow what i said all the time.



Well, Jamas answer this for me. Is dwamish architecture faster and less scalable than PetShop architecture ? That's what im talking about here.



Well provided your code is optimal, you can't keep throw hardware in to one machine... I mean you can't keep throwing in cpu in to one computer cuz the computer simple won't support more than 16 CPU max...



Are you saying that you have set of best practices (for architecture) that applies to every single application that are out there?



Thank you for that comment.. That really makes me feel good. YES I have designed a CMS larger than Ibuyspy. Maybe I was to general in saying CMS. Though, are you saying IBUYSpu arch is not suited for big CMS? Then you are contradicting your self. I thougth you said you can build scaleable etcetc app with the "procedural design"?!?!? or can u ?

I appreciate your criticism, though many of the things u've mentioned are really debatable...

Jamon, while you are entitled to your opion, i belive that james article is correct. I did not find it at all confusing, and it shed some light apon matters that were of concern to me.

In defence of james and his article, James is a volunterry writer who likes to share his knowledge. So criticising his ability is too harsh and "tight'. Criticising his work is understandable but him as a developer is not right. Im sure your book has received worse comments. I find it very unprofessional that you actually attach james in a personal sense.

"The author does not know his subject well. My intention is none other than to point out some of the incredible jumps and factors that I find in articles all the time and this one contained more assumptions and bad elements than I have seen in a long time."

While everyone is not perfect, this is still no reason, to take a personal attack at james, who is after all trying to express his knowledge.

Hi Ben, A couple of points which I would like to state:

I don't think that authors should publish if they are unable to absorb some criticism from time to time. Anyone author who has to justify what they said, probably didn't make their point clearly in the first place. When using such phrases as 'there is', 'there are', 'it has' the author is indicating a firm belief - James is right in saying that the criticism he received was debatable, but in making such sweeping rigid statements such as 'You should always design all three layers before building the actual application', I find it hard to support him on this occasion(incidently please see such sites as ww.extremeprogramming.org for much argument on this topic). Debate is healthy.

There is a level of social responsibility to be taken on when publishing material to the public - therefore material should be scrutinised and debated. I don't think that James was being personally attacked - if the criticism is levelled at the content of the article then that is fair. If you use your own experience as a reference point then it is only fair for it to be discussed too.

And James, being 'appreciative' of criticism and then being very obviously upset doesn't help....

Hi,

Nah Im not offended at all. I like criticisms.. they are the only way you can imrpove..
(ok..maybe not totally not offended. i was a bit upset about. Not about the comment on the article but comment on my programming ability)

About 'You should always design all three layers before building the actual application'. I always think its best to design what you are going to build b4 you actually start building it rather than start building it and then realise that something isn't gonna work... what do you think?

James

Some people believe in full design up front.

Others believe in not designing or doing very minimal - an evolution.

Some enjoy iterative design and development cycles

No one is disputing your point of view on the design element.
particularly it is the phraze -
'You should always design all three layers before building the actual application'

In this you are saying (maybe not what you meant?)
that we should design three layers up front.

This would be similair to me saying something like
you should always design for 2 tiers, or You should have exactly 16 patterns in your design.

It is a profound statement and would you not agree that it would be ill of me to present such statements?

Jamon

Hm...i think we are having a miscommunication..

When i say 'You should always design all three layers before building the actual application'

my emphasis is in "design" not "three layers". Meaning always plan b4 you start building it! Or more to what i said in that phrase. . . design the tiers and layers b4 u build it. So know b4 you build-

- What each layer is gonna do,
- How they are going to communicate, dataset, custom collection, web service, remoting...etc etc
- What dbms you will be using
- which design pattern u will be using

Its not necessarily...have 2 layers and use 16 patterns but rather decide how many and what type of layers you will be having and which patterns you will be using...

Jamon,

were u happy with my response to your criticisms? I would like to know if you still feel the same way about what ive said in the article or if my response changed your view in anyway. That way, i would know if I need to do some more research, and fix the articel up or provide more information, (maybe URL to other websites that agree with me). Because I know, now, that i did somethign wrong with the article. whether the content was wrong or whether the wording of some of the things were ambigous. I know There were somethign wrong with it, cuz you as a reader didn't really understnad what i really meant to say..(i'm sure you know what i mean.. since u are an author yourself. Somethings dont turn out the way you want it to)

James

I think that for the most part you really did try and get your points across. I would agree that there were times when it was not clear and you are now probably aware of some of these.

Although the written element is only one part of my post.

I did not actually highlight all the points for time sake, and I am not in a position to go through every point with you, but yes I do think you should add some references, and make sure that the wording is slightly less categorical on the debatable issues. I think you should find more than two sources that agree, and not just one.

Overall, I do know what you mean - there are articles out there that make similar mistakes and assumptions. In fact I can see some MSDN articles (not word for word - but the thoughts) in your article.

Read some architecture related stuff, perhaps CBD stuff or articles on OMG for a more diverse opinion set, instead of just MSDN. I am not saying you only read MSDN, but I am saying we should all read from a wide variety of sources.

If you had said - It is my opinion that ....
then I would probably not have mentioned a thing. This is an important aspect.
Also - referring to you previous post, if *design* is important then why not just say that. You could then mention that it is important in different ways - perhaps mentioning some different methodologies. - this would provide the reader with some good insights into other ways of doing things.

I can sense that you are over the initial shock of my post
Now we can chat!

Welcome to devarticles !