3 tier architecture and 3 layer architecture are not same?
I heard some saying 3 layer architecture is Application layer,business logic,Data layer in your application.But if these 3 layers are put in 3 different machines then it is 3 tier application.
Is it correct?
Generally, they are one and the same; however, this might be a good way to think about it.
Each "layer" is a logical grouping of code. Each "tier" is where the code lives. If you need to scale out, it makes sense to have each "layer" on its own "tier" (thus making them one and the same), but there is no reason they could not all be on the same machine, or even the same process.
Related
i used to do a racing game but a year ago i take a break (the project was done on unity 4), since i restart with that project i must reimplement the network because it doesn't work well with the unity 4 network. Now i saw that the are 2 ways to implement it using UNET, the HLAPI and the LLAPI, since the synchronization is very important for me the LLAPI should be better and flexible but i'm here to ask some experts if the effort to use it makes sense or the HLAPI give enough good results.
I don't think it's "LLAPI vs HLAPI".
LLAPI is a part of HLAPI. This is the lowest level :
Everything is flexible.
For example, i'm not using the "highlevel" (Engine Integration) NetworkTransform class, because this is crap, but i'm using the NetworkServer, at a lower level (Connection Management) because it's well done and you can override everything.
So it's not HLAPI vs LLAPI, HLAPI is a Ladder and your just chose which levels can be used "as is"
I know some devs are making their own Serialization, but still using higher levels. Globally it works really well EXCEPT the "Engine Integration" level that is just to me a bad written example (or useful only for card games etc...)
From last few days i have been searching the optimal architecture for my new web application, which would be devloped in ASP.Net using C#. Until now, i only find and study following 3
Three Tier Architecture (Note: By
Tier i mean logical layer)
Model View Controller (MVC)
Model View Presenter (MVP)
Now folling are my questions:
1) As far as i understand 3 Tier Architecture and MVP can I say that MVP and 3 Tier are
the same thing? If not, then what is the difference bewtween both? (Note: I only find
the difference between MVC and MVP or MVC and 3 Tier Archi but no one adress the diff
between MVP and 3 Tier Archi)
2) I only discover above three architectural options, is there any other options
available too? (Note: Here i want only the options for overall architecture of web
application,like above 3)
From a software architecture perspective; we use terms because terms mean something. When you use a term like "3-tier", you should use it where it fits it's intended and understood meaning. All sorts of things could be deemed "3-tier" simply by virtue of having three discrete components of some sort. But, if you used that term to describe MVP, you'd be misleading the other person. Why not simply say "MVP"?
3-Tier generally refers to three physical tiers. And Wikipedia has a great article on it here.
With the associated diagram:
Neither MVP nor MVC exclude using these three physical tiers. In fact, simply coining your application as an "MVC" application (or "MVP") doesn't really clarify much anymore. For example, it could be MVC on the server side (as in ASP.NET MVC) or it could be MVC on the client side with Javascript, or both!
As far as your question about architectural options; the playing field is pretty wide-open. The choices you make typically depend on a number of factors which you should be collecting while you collect your application requirements.
Often times you must make a trade off between Scalability and Complexity. However, a number of new technologies are making this trade off negligible - and I'd advise anyone starting a new project to consider them seriously (some discussed below).
It's almost always best to have, physically, a dedicated data tier (SQL, Mongo, Azure, Amazon, take your pick), and a dedicated, scalable, logic tier (usually implemented these days as WCF services in .NET land).
Most times people join their website and logic tiers... but this doesn't have to be the case. Sometimes it makes sense to have a physical tier exclusively for web services which are only accessible by your web site tier. Again, it's all situation-dependent.
As far as logical layers go (within your logic tier) it's almost always best to have some sort of data access layer (DAL), an in-code model (whether implemented manually, or through something like LINQ-to-Entities), and a dedicated business logic layer.
More and more these days people seem to be falling back to classic HTML and Javascript (with the help of things like JQuery, Prototype, DOJO, etc.) and using REST/JSON to chat with web services for retrieving and displaying data on the client side. In this scenario you can have a full-blown application on the client side, and another full-blown application in your back end... each with their own implementations of the logical layers I described above.
Options are wide open.
My take on things:
3-tier is not the same as MVP/MVC.
Many folks interpret the "Model" as a very broad concept that could contain lots of behaviour (including domain logic). I don't. The model is what the view needs to render itself. Sometimes it may have behaviour but, once again, only for behaviour related to view rendering.
With MVP you have a 1-1 mapping between the View and the Presenter. Although conceptually you could have more in reality it probably won't turn out that way. The presenter is only concerned with mediating between other layers and the view.
With MVC there is in all probablity more than 1 view that the controller deals with since it is concerned with flow.
So MVC/MVP can be used together and are front-end related and are part of the n-tier architecture.
Hope that makes sense.
You will see in answers such as this What are MVP and MVC and what is the difference? That MVC and MVP are addressing the structure of the code concerned with UI. They address questions such as:
Which component understands the user's actions?
Which component decides what view to present next?
What is the relationship between View and Model?
Neither MVC nor MVP go into details of what's inside (or beneath) the Model. In some systems the Model is comparatively simple, just a thin skin on top of a database, in other systems there's an awful lot of logic down there, for example integration with Enterprise systems such as SAP and CICs.
In its traditional meaning a 3-tier architecture (or more generally an n-tier architecture) puts additional structure inside the Model.
This wikipedia article discusses MVC v n-tier architectures. I think it's reasonable to substitute MVP for MVC in this article.
As to your application's architecture: my perception is that modern apps tend to have a rich UI presented in the browser, using simple REST services supplied by a Model on some server and then some arbitrarily complex stuff in the model. I guess you can see this as an n-tier architecture. The interesting thing is that as you structure your Javascript (JQuery, Dojo or whatever) in teh browser you find design patterns coming out, and an MVC pattern actually can emerge purely in the presentation tier.
I've always heard about the 3 layer approach (Presentation + Business logic + Data access) and that's the way I've always worked (adding a "4" layerif I count the database itself), but I'm wondering if this is all about layer and tier architecture (I already know the difference between layer and tier), is there a 5+ tier approach?, I've also heard about the controller, service and the application tier, how does this fit on the context?
Thank you,
There can be several layers. Do not confuse layers with tiers. Article explaining the difference: http://davidhayden.com/blog/dave/archive/2005/07/22/2401.aspx
Five layers:
RIA -> ASP.Net MVC -> WebService -> Business layer -> ORM.
It simply boils down to what you need and how you implement those requirements. I would not stare me blind on layers but to make sure that everything follows Single Responsiblity principle and Don't Repeat yourself. Doing so will often lead to different layers naturally.
Our company builds several (Java) applications that loosely communicate with eachother via web services, remote EJB and occasionally via shared data in a DB.
Each of those applications are build and maintained by their own teams. 1 or 2 persons for the smaller apps, and almost 10 for the largest one. The total amount of developers is approximately 25 FTE.
One problem we're facing is that there are some big egos among the teams. Historically the team of the largest app has set up a code convention and general guide lines. For instance our IDE is Netbeans, we use Hg for SCM, build with Ant and emphasize to first use as much from Java EE as possible, if that doesn't suffice use an external library and only resort to writing something yourself as a last resort. Writing things like yet another logging framework, orm, cms or web framework is pretty much not allowed following these guide lines.
Now some of the smaller teams go against this and start using Eclipse, Git and Maven and have an approach of writing as much as possible themselves and only look at existing things if time is short or they 'just don't feel like writing it themselves'. Where the main team uses log4j, one of the smaller teams just started writing their own logging framework.
There have been talks going on about all teams adhering to the same standards, but these have been 'troublesome' at best.
Now the big question I'd like to ask: does it actually matter that different teams do things differently? As long as each seperate app implements its requirements and provides the agreed upon interfaces, should we really force everyone to use Hg, Ant, the same code conventions, etc etc?
There is not much harm in letting each team use the technologies that work best for them. In fact if you restrict teams to the "standard" way of doing things you'll stifle innovation and have bad morale.
But you don't want things to diverge too much. There a few things you can do to prevent libraries and tools getting out of hand. The first thing is to have regular rotation of each member through the teams to cross pollinate ideas. In this way the best ideas will spread through the teams.
You can also enforce a "rule of 3", which simply says it is ok to introduce a second library, tool, logging approach, whatever. But as soon as you want to introduce a 3rd one, you have to remove one of the first two. In other words it is ok to have 2 competing logging frameworks but if there are 3 logging frameworks, choose one to kill.
A 3rd idea is to let developers run regular presentations to the entire developer group to demonstrate the pros and cons of each idea or approach. Encourage lots of discussion and constructive criticism. The purpose is to try many things and let everyone find the best way as a group.
Finally, Management 3.0 talks a lot more in depth about how teams make decisions. Well worth the read.
original question
when should i use multi-tier web application instead of single tier web application?
update to my question
i accepted the following definition to differentiale "Tier" and "Layer"
Layers Refer to specific layers of abstraction with in an application (software) where as tiers Refer to the physical residence of those layers (hardware)
App.Layer == "Software"-----logical
App.Tier == "Hardware"------physical
Layers:
1) presentation layer
2) business layer
3) data access layer
4) data layer
5) external system access layer
Tiers:
1) Presentation tier (webserver)
2) Data tier (database server)
Let's start by asking, will the application hold data? If it does, is the data going to be read by multiple users concurrently? How often? Based on the answer to these questions (and many other) you might want to decide whether a database is the way to go.
As far as layers (UI, Data Access, Business Logic, etc) is concerned, it trully depends on a project by project basis. Are you developing a web app for proof of concept? Are you expecting it to maintain it? Do you trust all the developers in your team? But my rule of thumb is to alway use layers unless i'm throwing something together really quick to either prove something or know it will never be maintained and I need to do it fast.
If you decide to use a framework such as MVC, MVP, MVVM, etc then by default you're dividing your app into layers.
Keep in mind that these divisions help you isolate certain aspects of your app, which in turn allow you to easily work with TDD, separation of concerns, maintainabilty, etc.
In conclusion, you have to look at your requirements, goals, team members, and short and long term objectives and decide. There is no white or black answer here
when should i use multi-tier web application (Tier == "Hardware"------physical)
Scalability.