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.
Related
I have gone through few posts like THIS and THIS, etc. but I couldn't clarify a confusion with respect to design that's in my mind. What would be the best practice to add CRUD for related entities when working with micro services? (my question is generally related to microservices, but currently I'm using aspboilerplate, to be specific)
For instance, I have an entity Product having around seven to ten properties in it. And then we may have another entity ProductContract. Each product can have multiple contracts added/updated.
Question: is it a good idea to create a separate Application Service for ProductContract entity? as it is going to have it's own input/output Dtos and logic, etc.
OR
It is better to create a ProductContractManager and keep its logic there. Then inject this manager into Product Application Service? This way, Product Application Service would have methods like 'AddProductContract', 'UpdateProductContract', etc.
The main driver of whether ProductContract should be owned by a different service is the consistency requirements, because achieving stronger levels of consistency between microservices is difficult (especially without tying the services together at the DB level: if going down that way, the decision to have separate microservices should probably also be revisited). So the main question you want to ask is, if updating/deleting a Product can there be a window of time where that update/delete isn't reflected in ProductContract (and vice versa)?
If the answer to that is that it can't, then you'll save yourself a lot of trouble by just putting responsibility for ProductContract in the same service that has responsibility for Product. If eventual consistency is allowed, then a separate service might be called for: the consideration there isn't really technical but more related to human organization (who will be developing and maintaining the functionality) and expectations around whether ProductContract and Product will evolve together (functionality changes in one being likely to also lead to functionality changes in the other).
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.
I work for a firm that provides certain types of financial consulting services in most states in the US. We currently have a fairly straightforward CRUD application that manages clients and information about assets and services we perform for each. It only concerns itself with the fundamental data points and processes that are common to all locations--the least common denominator.
Now we want to implement support for tracking disparate data points and processes that vary from state to state while preserving the core nationally-oriented system. Like this:
(source: flickr.com)
The stack I'm working with is ASP.Net and SQL Server 2008. The national application is a fairly straightforward web forms thing. Its data access layer is a repository wrapper around LINQ to SQL entities and datacontext. There is little business logic beyond CRUD operations currently, but there would be more as the complexities of each state were introduced.
So, how to impelement the satellite pieces...
Just start glomming on the functionality and pursue a big ball of mud
Build a series of satellite apps that re-use the data-access layer but are otherwise stand-alone
Invest (money and/or time) in a rules engine (a la Windows Workflow) and isolate the unique bits for each state as separate rule-sets
Invest (time) in a plugin framework a la MEF and implement each state's functionality as a plugin
Something else
The ideal user experience would appear as a single application that seamlessly adapts its presentation and processes to whatever location the user is working with. This is particularly useful because some users work with assets in multiple states. So there is a strike against number two.
I have no experience with MEF or WF so my question in large part is whether or not mine is even the type of problem either is intended to address. They both kinda sound like it based on the hype, but could turn out to be a square peg for a round hole.
In all cases each state introduces new data points, not just new processes, so I would imagine the data access layer would grow to accommodate the addition of new tables and columns, but I'm all for alternatives to that as well.
Edit: I tried to think of some examples I could share. One might be that in one state we submit certain legal filings involving client assets. The filing has attributes and workflow that are different from other states that may require similar filings, and the assets involved may have quite different attributes. Other states may not have comparable filings at all, still others may have a series of escalating filings that require knowledge of additional related entities unique to that state.
Start with the Strategy design pattern, which basically allows you outline a "placeholder", to be replaced by concrete classes at runtime.
You'll have to sketch out a clear interface between the core app and the "plugins", and you have each strategy implement that. Then, at runtime, when you know which state the user is working on, you can instantiate the appropriate state strategy class (perhaps using a factory method), and call the generic methods on that, e.g. something like
IStateStrategy stateStrategy = StateSelector.GetStateStrategy("TX"); //State id from db, of course...
stateStrategy.Process(nationalData);
Of course, each of these strategies should use the existing data layer, etc.
The (apparent) downside with this solution, is just that you'll be hardcoding the rules for each state, and you cannot transparently add new rules (or new states) without changing the code. Don't be fooled, that's not a bad thing - your business logic should be implemented in code, even if its dependent on runtime data.
Just a thought: whatever you do, completely code 3 states first (with 2 you're still tempted to repeat identical code, with more it's too time-consuming if you decide to change the design).
I must admit I'm completely ignorant about rules or WF. But wouldn't it be possible to just have one big stupid ASP.Net include file with instructions for states separated from main logic without any additional language/program?
Edit: Or is it just the fact that each state has quote a lot a completely different functionality, not just some bits?
My question is possibly a subtle one:
Web services - are they extensions of the presentation/web layer? ..or are they extensions of the biz/data layer?
That may seem like a dumb question. Web services are an extension of the web tier. I'm not so sure though. I'm building a pretty standard webform with some AJAX-y features, and it seems to me I could build the web services in one of two ways:
they could retrieve data for me (biz/data layer extension).
example: GetUserData(userEmail)
where the web form has javascript on it that knows how to consume the user data and make changes to markup
they could return completely rendered user controls (html; extension of web layer)
example: RenderUserProfileControl(userEmail)
where the web form has simple/dumb js that only copies and pastes the web service html in to the form
I could see it working in either scenario, but I'm interested in different points of view... Thoughts?
In my mind, a web service has 2 characteristics:
it exposes data to external sources, i.e. other sources than the application they reside within. In this sense I agree with #Pete in that you're not really designing a web service; you're designing a helper class that responds to requests in a web-service-like fashion. A semantic distinction, perhaps, but one that's proved useful to me.
it returns data (and only data) in a format that is reusable by multiple consumers. For me this is the answer to your "why not #2" question - if you return web-control-like structures then you limit the usefulness of the web service to other potential callers. They must present the data the way you're returning it, and can't choose to represent it in another way, which minimises the usefulness (and re-usefulness) of the service as a whole.
All of that said, if what you really are looking at is a helper class that responds like a web-service and you only ever intend to use it in this one use case then you can do whatever you like, and your case #2 will work. From my perspective, though, it breaks the separation of responsibilities; you're combining data-access and rendering functions in the same class. I suspect that even if you don't care about MVC patterns option #2 will make your classes harder to maintain, and you're certainly limiting their future usefulness to you; if you ever wanted to access the same data but render it differently you'd need to refactor.
I would say definitely not #2, but #1 is valid.
I also think (and this is opinion) that web services as a data access layer is not ideal. The service has to have a little bit more value (in general - I am sure there are notable exceptions to this).
Even in scenario 1, this service is presenting the data that is available in the data layer, and is not part of the data layer itself, it's just that it's presenting data in a different format than a UI format (ie. JSON, xml etc.)
Regards which scenario I would use, I would go for scenario #1 as that service is reusable in other web forms and other scenarios.
While #1 (def. not #2) is generally the correct approach (expose just the data needed to the view layer and have all markup handled there), be careful with the web portion of the service in your design.
Data should only be exposed as a web service (SOAP/WSDL, REST) if it is meant to be consumed remotely (some SOA architects may argue this, but I think that is out of scope for this question), otherwise you are likely doing too much, and over-designing your request and response format. Use what makes sense for your application - an Ajax framework that facilitates client/server communication and abstracts the underlying format of communication can be a big help. The important thing is to nicely encapsulate the code that retrieves the data you want (you can call it a service, but likely it will just be a nicely written helper class) so it can be re-used, and then expose this data in whatever way makes the most sense for the given application.