Three-Tier Architecture Vs MVC

Three-Tier Architecture

Three-tier architecture is perfectly good for describing the overall design of a software product, but it doesn’t address what happens inside the UI layer. That’s not very helpful when, as in many projects, the UI component tends to balloon to a vast size, amassing logic like a great rolling snowball.

It shouldn’t happen, but it does, because it’s quicker and easier to attach behaviors directly to an event handler (a la Smart UI) than it is to refactor the domain model. When the UI layer is directly coupled to your GUI platform (Windows Forms, Web Forms), it’s almost impossible to set up any automated tests on it, so all that sneaky new code escapes any kind of rigor. Three-tier’s failure to enforce discipline in the UI layer means, in the worst case, that you can end up with a Smart UI application with a feeble parody of a domain model stuck on its side.

MVC Architecture

In this architecture, requests are routed to a controller class, which processes user input and works with the domain model to handle the request. While the domain model holds domain logic (i.e., business objects and rules), controllers hold application logic, such as navigation through a multistep process or technical details like authentication.

When it’s time to produce a visible UI for the user, the controller prepares the data to be displayed (the presentation model, or ViewData in ASP.NET MVC, which for example might be a list of Product objects matching the requested category), selects a view, and leaves it to complete the job. Since controller classes aren’t coupled to the UI technology (HTML), they are just pure application logic. You can write unit tests for them if you want to. Views are simple templates for converting the view model into a finished piece of HTML. They are allowed to contain basic, presentation-only logic, such as the ability to iterate over a list of objects to produce an HTML table row for each object, or the ability to hide or show a section of the page according to a flag on some object in the view model, but nothing more complicated than that. By keeping them simple, you’ll truly have the benefit of separating application logic concerns from presentation logic concerns.

Separating Out the Domain Model

Given the limitations of Smart UI architecture, there’s a widely accepted improvement that yields huge benefits for an application’s stability and maintainability.

By identifying the real-world entities, operations, and rules that exist in the industry or subject matter you’re targeting (the domain), and by creating a representation of that domain in software (usually an object-oriented representation backed by some kind of persistent storage system, such as a relational database or a document database), you’re creating a domain model.

What are the benefits of doing this?

• (Easy To Maintain) First, it’s a natural place to put business rules and other domain logic, so that no matter what particular UI code performs an operation on the domain (e.g., “open

a new bank account”), the same business processes occur.

• (No Source Code Duplications) Second, it gives you an obvious way to store and retrieve the state of your application’s universe at the current point in time, without duplicating that

persistence code everywhere.

• Third, you can design and structure the domain model’s classes and

inheritance graph according to the same terminology and language used by

experts in your domain, permitting a ubiquitous language shared by your programmers and business experts, improving communication and increasing the chance that you deliver what the customer actually wants (e.g., programmers working on an accounting package may never actually understand what an accrual is unless their code uses the same terminology).

In a .NET application, it makes sense to keep a domain model in a separate assembly (i.e., a C# class library project—or several of them) so that you’re constantly reminded of the distinction between domain model and application UI. You would have a reference from the UI project to the domain model project, but no reference in the opposite direction, because the domain model shouldn’t know or care about the implementation of any UI that relies on it.

For example, if you send a badly formed record to the domain model, it should return a data structure of validation errors, but would not attempt to display those errors on the screen in any way (that’s the UI’s job).

Can you find System.Web in add reference ? [.NET 4.0]

Today I was tried to use the method in "System.Web.HttpUtility.UrlEncode", but intelligence only shows three classes under System.Web.

After goggling I found that I need to add a .NET reference to "System.Web.dll" because I am making a Windows Application.

But unfortunately I could not find where is the "System.Web.dll" ? Its not available in the .NET references . :(

Finally figure out why is that! Yeah its because, I have targeted the Windows application to .NET framework4.0

But that's no an excuse I know;

Meanwhile I did further investigation of why it was not showing in the add reference tab of 4.0 project.

Yeah I got the issue, this is because, by default the project created in Framework 4.0 is defaulted to the profile.

Open the project properties and you can see it as shown below.

We can change this profile to .Net Framework 4.0 as shown below.

Once you have done this, you can go and add the reference to System.Web

Hope this helps!!!

What’s New in ASP.NET MVC 2

Since ASP.NET MVC 1 reached its final release in April 2009, the developer community has been hard at work applying it to every conceivable task (and a few inconceivable ones). Through experience, we’ve established best practices, new design patterns, and new libraries and tools to make ASP.NET MVC development more successful.

Microsoft has watched closely and has responded by embedding many of the community’s ideas into ASP.NET MVC 2. Plus, Microsoft noticed that certain common web development tasks were harder than expected in ASP.NET MVC 1, so it has invented new infrastructure to simplify these tasks.

Altogether, the new features in ASP.NET MVC 2 are grouped around the theme of streamlining

“enterprise-grade” web development. Here’s a rundown of what’s new:

• Areas give you a way to split up a large application into smaller sections (e.g., having a public area, an administrative area, and a reporting area). Each area is a separate package of controllers, views, and routing configuration entries, making them convenient to develop independently and even reuse between projects.

• Model metadata and templated view helpers are extensible mechanisms for describing the meaning of your data model objects (e.g., providing humanreadable descriptions of their properties) and then automatically generating sections of UI based on this metadata and your own design conventions.

• Validation is now far more sophisticated. Your model metadata can specify validation rules using declarative attributes (e.g., [Required]) or custom validators, and then the framework will apply these rules against all incoming data. It can also use the same metadata to generate JavaScript for client-side validation.

• Automatic HTML encoding (supported on .NET 4 only) means you can avoid cross-site scripting (XSS) vulnerabilities without remembering whether or not to HTML-encode each output. It knows whether you’re calling a trusted HTML helper, and will make the right encoding choice automatically.

• Asynchronous controllers are relevant if you must handle very large volumes of concurrent requests that each wait for external input/output operations (e.g., database or web service calls). These build on ASP.NET’s underlying IHttpAsyncHandler API, potentially boosting performance in such scenarios.

• HTTP method overriding is very neat if you’re exposing a REST-style interface to the Web with the full range of HTTP verbs such as PUT and DELETE. Clients that can’t issue these HTTP request types can now specify an override parameter, and then the framework will transparently accept that as the request’s HTTP verb.

• Strongly typed input helpers let you map input controls (e.g., text boxes or custom

templates) directly to your model objects’ properties with full IntelliSense and refactoring support.

• Child requests are a way to inject multiple extra independent sections into a page (e.g., a navigation menu or a “latest posts” list)—something that doesn’t otherwise fit easily into the MVC pattern. This is based on the RenderAction() mechanism previously included in the “MVC Futures” add-on for ASP.NET MVC 1.

Like any other version 2 product, there’s also a host of smaller improvements, including extra

extensibility options and performance optimizations. I will explain all the above areas one by one from my furture posts. Times up now!! Need to go to office.. catch u guys !! :)

ASP.NET Web Forms Vs ASP.NET MVC

You’ve already heard about the weaknesses and limitations in traditional ASP.NET Web Forms from my previous post (http://upulsgamage.blogspot.com/2010/11/whats-wrong-with-aspnet-web-forms.html). That doesn’t mean that Web Forms is dead, though;

Microsoft is keen to remind everyone that the two platforms go forward side by side, equally supported, and both are subject to active, ongoing development. In many ways, your choice between the two is a matter of development philosophy.

• Web Forms takes the view that UIs should be stateful, and to that end adds a

sophisticated abstraction layer on top of HTTP and HTML, using ViewState and postbacks to create the effect of statefulness. This makes it suitable for

drag-anddrop Windows Forms– style development, in which you pull UI widgets onto a canvas and fill in code for their event handlers.

• MVC embraces HTTP’s true stateless nature, working with it rather than

fighting against it. It requires you to understand how web applications actually work; but given that understanding, it provides a simple, powerful, and modern approach to writing web applications with tidy code that’s easier to extend and maintain over time, free of bizarre complications and painful limitations.

There are certainly cases where Web Forms is at least as good as, and probably better than, MVC. The obvious example is small, intranet-type applications that are largely about binding grids directly to database tables or stepping users through a wizard. Since you don’t need to worry about the bandwidth issues that come with ViewState, don’t need to be concerned with search engine optimization, and aren’t bothered about unit testing or long-term maintenance, Web Forms’ drag-and-drop development strengths outweigh its weaknesses.

On the other hand, if you’re writing applications for the public Internet, or larger intranet

applications (e.g., more than a few person-month’s work), you’ll be aiming for fast download speeds and cross-browser compatibility, built with higher-quality, well-architected code suitable for automated testing, in which case MVC will deliver significant advantages for you.