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.
Related
I have a few quick questions about the use of the business logic layer in the average N-Tier architecture application.
I am developing my final year university project, and using a web forms presentation layer, business logic layer, data access layer and data layer.
1) What are your opinions on where is the best place to perform user input validation? To me it makes sense to use the presentation layer with something like jQuery validation for client side, and ASP.NET validation controls for server-side validation - however plenty of articles state it is best to perform validation in the BLL?
2) Currently my BLL is fairly thin, 90% of the classes simply act as an interface to the DAL, however I do know there will be more there eventually. In my DAL I have multiple select commands for each entity, e.g. GetAllProducts(), GetProductsByCategoryID(categoryID), GetProductByProductID(productID), GetProductsBySupplierID(supplierID). This appears to have a low level of business logic involved, i.e. technically there should simply be a GetAllProducts() function, which could be filtered using code in the BLL.
What is your opinion on the best practices for this? One select statement with filtering in the BLL, or as many select statements as needed to get the data I want? I would imagine always selecting every product would get pretty heavy on resources on large scale apps, however at least there is a true separation of logic between tiers.
Cheers,
Stu.
i don't think so you need to have bll. you just need to have two layers. WebUI and DAL.
and the use of linq to sql or lambda expression with Data entity model will be the perfect recipe.
One select statement with filtering in the BLL, or as many select statements as needed to get the data I want?
you should go for filtering in the bll as it is your final pro, if you need to use all the layers. it will so helpfull when u reuse your code. Do make filters in BLL.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
A modern n-layer asp.net web application sample?
I'm having a hard time trying to design a solid N-Tier framework in ASP.Net. I know the basic fundementals: BLL, DAL, and Business Objects, etc. What I can't understand is the actual flow of the application and what the return types in the BLL and DAL should be.
Most articles I've read have suggested that the BLL and DAL communicate via Business Objects. However I don't see the real benefit if I have to instantiate the Business Object twice during each pass.
Does anyone have any links to good tutorials/sample applications that could guide me in the right direction?
Thanks
First, you must understand that tiers and layers are different things, although they are often confused. A layer is a software abstraction. the L in DAL stands for Layer. The last L in BLL stands for Layer.
A tier is a physical seperation of some type. At the loosest definition, merely putting you DAL in a seperate assembly is considered a Tier, although I am a bit more narrow in my definition. I consider a tier to be a physically seperated component that does not require being run on the same computer (although it may run on it, it doesn't need to).
To answer your question, though. Yes, Business Objects are typically used to transfer data (also called Data Transfer Objects, or DTO's). I'm not sure what you mean by having to instantiate the object twice. Can you be more specific?
Don't know if you've already run into this article on msdn. If not it could be worth reading as they discuss designing tiers in general and DAL in particular, differences, pros and cons of different approaches. I think they use the same terminology as you do. Designing Data Tier Components and Passing Data Through Tiers
You could be also interested in answers to the similar question here.
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.
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.
While designing (and then implementing) a layered application:
Is it correct to use the same ORM objects accross all layers? (which would go against encapsulation).
Or the presentation, business and data layer should each have their own objects? (which would lead to lots of code repetition).
e.g. (just to illustrate the question): if one uses Linq to SQL in the Data Layer and Visual Studio's O/R designer to generate the ORM objects, are those objects supposed to be used in the Business and Presentation Layers as well.
i.e.: Are the objects associated with the entities that the application handles a crosscutting issue?
It depends by your business. if you are talking about a small application you could do it.
Usually the best practices wants to don't expose the entity from the DAL to the presentation because doing that the layer are going to be tightly coupled and you could expose data that doesn't make sense at the top layer (presentation)
on the other hand you shouldn’t create a bunch of object per each layer.
it's always hard answer this question because it really depends by your needs.
you can have a look at this book just to have an idea about
http://books.google.co.uk/books?id=FyWZt5DdvFkC&printsec=frontcover&dq=martin+fowler+enterprise+architecture&source=bl&ots=eEEx4ATr5C&sig=sSmDmffOSALWfFZEaPyhkwwEq_I&hl=en&ei=SJnSTMuSJIHm4AaK9tW5Dw&sa=X&oi=book_result&ct=result&resnum=6&ved=0CDAQ6AEwBQ#v=onepage&q&f=false