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.
Related
I am trying to make a website in ASP.NET MVC, but I am not really sure how I should organize things. N-Tier applications seem to work nice, but since I am a beginner programmer it is pretty hard to understand. I just want to create a small web application where people can login and create pages. In these pages they can add others things. The database won’t be bigger than 10 tables I think. Even though it is a small application, I would like to use some best practices that N-Tier applications use.
Is this a good approach? Or is it very wrong? :
Project.Models
Models that represent the entities in my database.
Project.DAL
Interfaces and implementations for my repositories and unit of work. Also my NHibernate mappings.
Project.BLL
Interfaces and implementations for my services.
Project.UI.Web.MVC
My controllers, viewmodels and views. The controllers get data from services and pass data (viewmodels) to views so I think it’s part of the UI.
There are no hard and fast rules about how to organise your project.
That looks pretty logical to me and seems to follow a lot of hte examples that i have seen across the internet.
All that matters is that its logical to you and your team in my opinion.
Take a look at this link as well, might be a lot of useful information for you there:
Best practices for MVC architecture
That sounds like a neat layering.
Define clearly on what goes in DAL, BLL and Web.MVC. Because people can have difference in opinion in what goes into business logic and ui logic, I suggest to have a weekly review of what has went into each layers - to start with.
One suggestion is to call Project.UI.Web instead of Project.UI.Web.MVC.
I recently worked at HP doing several ASP.NET MVC3 projects as I came from a software background I was relatively new to the inner workings of MVC3 as well as the best practices.
During this time I somewhat adapted the coding style of fellow co-workers and ways of designing my pages that I still stick with to this day. With all of this in mind my main question is what would anyone recommend for learning material; books/videos/tutorials. I can learn from any of those resources and I would love to know that I am coding properly.
I have several projects under my belt and many large scale business solutions that I have coded using Razor and ASP.NET but there are times where I feel that what I am doing is either very hacky or just an inefficient way of coding things. The larger the project is the more difficult it becomes to add new features because of this.
I think this is my lack of experience in coding but at the same time I would like to overcome this and I feel that with the mass experience I do have with MVC3 I could adapt to a easier style or design pattern that would help me not only optimize my code but become a much better web developer. If anyone has any suggestions on books or training sites or anything please let me know as I would love to get better.
Thanks in advance to anyone that has been in my shoes and is willing or capable of recommending anything!
I was dealing with the same issue and found it useful to make a mind map. While it's impossible to give you a full understanding, I can try point you in the right direction with some basic ideas.
download/view (http://www.xmind.net/share/highroad/mvc3-design-pattern/)
Are you familiar with design patterns? Well they exists with MVC applications too :)
If you want to talk the talk and understand what people including myself are talking about, you would need to know the typical design patterns that come with building what they call enterprise level applications. These design patterns are the only real way to begin to understand the concepts.
These patterns structure complex business logic in ways that have become the tried and tested solutions (design patterns) to the design challenges the developer's face.
In the diagram notice there are 3 main layers:
Presentation Layer
Business Logic Layer
Data Access Layer
Some of the highly used design patterns when dealing with Model View Controller in ASP.NET include:
Business Logic Layer Design Patterns:
Active Record. Models relate exactly to the database like in lightweight frameworks e.g. Ruby on Rails). When creating new MVC3 application with ASP.NET and scaffolding views and controllers, this is how it sets it up. Is perfect for less complex applications. So why not just use Ruby on Rails? I would
Domain Logic Layer. Uses MVC with the controller containing very little code and create lots of extra models that can do complex logic, the MVC is only for presentation. Often with this style of layer, a lightweight layer called a Service Layer can be used to call all the functions in the Domain Layer from the controllers i.e. the controller calls the method in the Service Layer class which calls the domain layer. This design pattern seems to be very popular with people who enjoy object oriented programming. See link below to my (quite basic) project designed using Domain layer.
Transaction Script - Use the controller to do a lot of the logic work per action, the problem is a lot of actions need to do the same things so there will be code repetition
For the Data Access Layer:
Something like entity framework models combined with a repository which can perform any SQL queries you need.
Not going into all the patterns for this layer but they include: Data Mapper
With simple apps, there is no real data access layer, it only becomes necessary if you use the Domain Layer in the business layer (which usually is the case)
Depending on what structure your application takes, your Models will mean very different things. In general they will not be models linked to the database (the default when creating a new app makes them like this). Instead they will be ViewModels which are only responsible for holding data that each of the views will need.
I have created a ssample app which you can see here.
https://github.com/testbrian/enterpriseframeworksB
I don't know if this is an example of an enterprise solution, but I have learned a lot from the techniques found in RaccoonBlog. I like how the Layout.cshtml and other razor files use RenderAction to modularize the views.
The project is an example of MVC3 using RavenDb, but it's also one of the best real world applications I've seen since it's actually used in production.
Hope this helps.
Can you advice on structering the solution projects, files, fodlers in a way that it matches with the MVP design pattern in order to represent the pattern idea?
I mean how would you put your presenters, data acces layer, views etc.
Thanks
Solution architectures are generally pretty independent of which UI architecture you're using, although you might have some additional separation if you plan to have multiple UI applications (most projects don't).
I tend to start out with a template similar to this:
Acme.Sales or Acme.Sales.Core - internal domain/business logic
Acme.Sales.Entities - data entities used for persistence layers. Entities have similar class structure to the core (domain) model, but tend to have thinner logic, additional properties like Id, two-way relationships (as opposed to the one-way relationships in the domain model), and virtual members for the ORM to be able to override. This assembly will also normally include abstract repositories for CRUD operations on entities.
Acme.Sales.Entities.Impl where Impl is something like LinqToSql or NHibernate - this namespace defines one possible implementation for actually persisting the Entities. Concrete implementations of the abstract repositories go here.
Acme.Sales.UI contains common classes relating to any user interface - might be an MVP GUI or even a CLI. As with Entities, these are similar to the Core classes but tend to have presentation-specific logic and attributes, such as validation and formatting (which most often today is done through DataAnnotations). Note that the core library should also validate, but UI validation tends to be more about formatting and sanitization of inputs than business rules. It's tempting to mimic the domain's class structure here, but you'll have an easier time overall if you stick to flat, DTO-style classes for your UI model.
Acme.Sales.UI.Services contains abstract or concrete "service" types that are meant to interact with both the UI and the domain/persistence layers. Thus this project takes dependencies on Acme.Sales (domain), Acme.Sales.Entities (abstract repositories), as well as Acme.Sales.UI, and handles all of the mapping activities between those different layers.
Acme.Sales.UI.Impl where Impl here is something like Mvp, Mvc,Mvvm, and so on. You can drop the UI from this namespace if you want, as the implementation implies what it is. This generally takes a dependency on the UI project but adds those things specific to a particular UI model; controllers, presenters, view-models, etc. This is your actual "application". It's also where you normally choose an IoC container (AutoFac, Ninject, Spring.NET, Castle, Unity) and wire up all the specific implementations to the abstract types.
Within your application project you'd want to separate logical concepts into different sub-namespaces/folders. For example put your presenters in Presenters and views in Views - pretty straightforward - and create subdirectories in each of those if you start getting a really huge number of screens (e.g. Views.Billing and Views.Shipping). It's also OK to create top-level Area directories/namespaces here and put separate Presenters, Views, etc. in each one of those areas - this is the approach currently taken in ASP.NET MVC.
You don't need to separate Presenters and Views into different projects. Rest assured that the views which you tailor-made for MVP will be utterly useless for MVC or MVVM, and vice versa. The only part of a model-driven app that really stands a chance of being reused is the model itself.
Note that this is just a very basic architecture for an app with a single database and relatively simple domain logic. It doesn't include any higher-level back-end constructs like app integration (e.g. web services), eventing (pub/sub), batch processing, CQS, ad-hoc reporting, and so on and so forth. These tend to be pretty common in larger-scale business apps but if you're just starting out on a new social bookmarking app then you don't need any of that complexity.
Also note: This is all assuming you're planning at least a medium-size project - let's say one that you and/or your team will be working on for 6 months or more. If you plan to bang it all out in 1 month or less then please, don't waste your time on solution architectures at all. It's perfectly OK to just jam it all into one project and reuse the same classes for domain, entities, and UI - as long as the project is small enough to be easily understood and maintained. Carefully monitor the complexity and maintenance overhead and consider refactoring into the above structure over a longer period of time if the project starts turning into a ball of mud.
Below would be a nice start. You could split up even more if the project gets bigger:
Company.Project.Core -> Controller logic
Company.Project.Domain -> Domain models (view models and database models)
Company.Project.Interface -> Views, presenters
I've recently implemented a simple dynamic forms engine that uses dynamically loaded ASP.NET controls in concert with an EAV schema to handle the variable nature of the data model. The business was sufficiently satisfied with the end product for a time, but is now clamoring for much more complex dynamic forms:
Field visibility is tied to the values of other form fields
List of drop down possible values tied to the state of other form fields
Enforcement of various business rules across the form: i.e. Value of FieldA must be no greater than FieldX + 30 days, assuming FieldX is not null, blah blah
Other complex inter-field dependencies and business rules
As you might imagine, I'm looking for an off the shelf solution since rolling such an engine from scratch seems tedious, time consuming and not really part of our core business. Ideally, I want complete ASP.NET framework (MVC or WebForms) that encompasses all layers (Business Logic, Presentation Layer and Persistence). Beggars can't be choosers, however, so I'd make do with a framework that only dealt with Business Rule definition and evaluation. Furthermore, I'm looking for a strictly server-side solution since my hands are tied by a strict policy that disallows any dependence on client side plug-ins.
XForms seems like a perfect fit, but the only mature implementations I've found are based on Java (Orbeon) or Django (Chiba). The other XForms implementations I've found have some kind of dependence on client-side plug-ins.
I'm open to using Orbeon if I can figure out a way to integrate it with an ASP.NET application, but I've see no actual examples of such a hybrid implementation.
I looked briefly at Microsoft Office InfoPath, but it doesn't seem nearly robust enough to handle the kind of complex scenarios I need to implement.
All ideas welcome!
You should have a look at betterform (http://betterform.de) too. It's a successor of Chiba and has many improvements in comparison to the original Chiba. It is open source and hosted at sourceforge as the original product.
I have read many articles on the MVP pattern. Some folks say it is too complex and some say it's outdated. However to me it would seem like the perfect way to provide unit testing access to the UI - which is what I'm aiming to achieve.
Have you used MVP and if so what do you think?
Model View Presenter, Model View Controller, traditional three tier (UI/Business Logic/Data Storage) or virtually any other architecture that isolates the various concerns of your code help you write tests.
Often the architecture is somewhat dictated by your tool: the Asp.Net MVP tags seem to indicate that you have already made your choice there. The trickiest part to test in any configuration is the UI, because even if you create a mock UI that performs all the functions the user can... at some point you will have to render it in a browser and assure yourself that the theory is sound.
Note that this does not discount the benefits of a mock presenter UI with unit tests that exercise all the options the user will have: doing so puts you light years ahead of someone doing straight UI testing alone. On the other hand, I have yet to find a program where the UI always rendered as we expected in every browser. Finding these cases still requires human intervention (or at best something like Selenium or Test Complete once you have the initial run-throughs).
Regarding the "obsolete" aspect, I think that is a red herring. There are of course religious wars regarding architectural choices, but the reason that MVP is being used in some ASP.NET projects is that there are quite a few who felt the traditional ASP.NET stack was too tightly integrated between the UI and the Business Logic. (I'm one of them.) For small projects that tight coupling isn't that big of a deal, and contributes to the quick "bring it up and running" ability of the form designer with databinding. In large projects, the limitations of these tools show up in a hurry, and having a "middle" tier hacked back in after the fact is a challenge: one you don't have to face with MVP.
I did an ASP.NET project using MVP last year. Yes, I was able to cover more with unit testing than I could before in the webforms world, but it felt hacky. Also, try explaining what you are doing to someone else. For some reason, people have a hard time grokking it. If I had to do it over again, I'd go with the ASP.NET MVC framework, since it is officially supported with tons of documentation and buzz, and not just a hack.