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!!!