Food for thought 2

While karl's Webforms Rant starts off strong and ends strong, the body gets a little whiny. I post it here because I'm convinced most .net devs don't realize there are alternatives to webforms.

I do agree with karl's point (albeit the delivery is weak). Webforms will always be more complicated because it works against the nature of statelessness and cannot be easily tested.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[ca8msm]

There's also the response from Scott Guthrie (manager of the ASP.NET team i.e. responsible for both architectures) with his thoughts on the MVC vs Webforms debate:

http://weblogs.asp.net/scottgu/arch...-web-forms-and-asp-net-mvc-in-particular.aspx

From my point of view, this sums up the whole debate in this one sentence:

Web Forms and MVC are two approaches for building ASP.NET apps. They are both good choices. Each can be the “best choice” for a particular solution depending on the requirements of the application and the background of the team members involved. You can build great apps with either. You can build bad apps with either. You are not a good or bad developer depending on what you choose. You can be absolutely great or worthless using both.

One isn't better than the other, this choice should be made entirely by the developers based on their working environment so there is no need for Karl's soapbox approach, just let each person decide what is best for them. Both have pros and cons and if you truly know how to use either then you can produce exactly the same end result whichever method you choose. How you get to that result may be easier/quicker/more logical for one team but quite the opposite for another.

Personally, I just don't get the whole "put down" culture people have about either technology; I'm happy with whatever route they chose and if I can help them out with any problems they have using either method then I'll try my best to help them answer they question they asked rather than do suggest they are "idiots" for picking one method over anothor.

Mark,

Darlington Web Design
Experts, Information, Ideas & Knowledge
ASP.NET Tips & Tricks

 

[jmeckley]

Mark, I agree there is no "right" answer. Having developed in both webforms and now MVC I have a difficult time understanding when Webforms is the better choice.

I believe webforms solved a symptom, not a problem. A majority of MS programmers were desktop developers. MS did not see the value of web applications in its infancy. Once they realized the web was gaining ground they needed to move developers to the web. So a desktop-like environment was created for the web... webforms. This cured the symptom. But the web isn't a desktop, it's http and html. concepts within a desktop application (statefulness, events) just don't exist. why fight against that (postback, page lifecycle, events) rather than accept it? The problem still existed. The desktop developers did not understand the web environment. Little was done to provide resources to their clients about what the web was.

if you look at the asp.net framework it's
(1) extensible - implement an interface and plug in to web.config. your set.
(2) simple - handler, module, application, context
(3) works with the concepts of http - key/value string pairs. a solid foundation to build web frameworks on.
(4) solves a single problem - servicing http requests.

Then look at webforms
(1) extensible - no, where can I over ride the html engine? how can I override page instantiation? what if I want/need to inject behavior around a member of a Page subclass?
(2) simple - events. what events, html doesn't have events.
postback. a request is atomic. postback is irrlevant.
viewstate. bloated html
server controls. html is just text, it's not complex like rendering a form on a desktop.
SOC - webforms doesn't promote separation of concerns. it encourages a developer to put all there code in the code behind. There is no way to configure/inject behavior into a Page subclass, so your next 2 options are Static factories or instantiation of objects within the Page itself.
(3) works with the concepts of http - why introduce complexity to a simple environment.
events, why? once the request is given to handler, get the data, render the html. should I really care if I'm loading a grid row, or done binding a drop down list? this type of processing belongs in the view (markup). not the controller (Page object)
postback - this just doesn't exist on the web
statefulness - this just doesn't exist on the web either
(4) solves a single problem - why on earth is an html engine (or page controller, since conceptually that's what a Page object is) concerned with how to retrieve the data. Why does are there dozens of properties to configure the display of the html when I have the power of CSS.

Then MVC
(1) extensible - all the MVC frameworks provide a mechanism to override the default behavior.
(2) simple - pass request to controller, controller gets data, controller sends data to view. view renders content.
(3) works with the concepts of http - getting data out of the request is simple. key/value pairs and ViewData Model hydration/binding are built in.
(4) solves a single problem - control the association of data to the view. the controller manages getting data from a source and sending it to a view. the view is responsible for rendering the data as html.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[ca8msm]

Mark, I agree there is no "right" answer. Having developed in both webforms and now MVC I have a difficult time understanding when Webforms is the better choice.

That's fine, it's your opinion and based on your development techniques and working environment. I understand that, I just don't agree that because you think MVC is a better choice for you why you think it is a better choice for everyone. It isn't.

I believe webforms solved a symptom, not a problem. A majority of MS programmers were desktop developers. MS did not see the value of web applications in its infancy. Once they realized the web was gaining ground they needed to move developers to the web. So a desktop-like environment was created for the web... webforms. This cured the symptom. But the web isn't a desktop, it's http and html. concepts within a desktop application (statefulness, events) just don't exist. why fight against that (postback, page lifecycle, events) rather than accept it? The problem still existed. The desktop developers did not understand the web environment. Little was done to provide resources to their clients about what the web was.

You make the assumption that people who use webforms think of it like a desktop application. I don't. I started web based programming actually using an MVC pattern in PHP in the 1990's and then changed tact to classic asp (which, by the way, had an all too similar feel to it - check out the PHP vs ASP from that time to see a very similar replica of the current debate that ended up fading away with both camps thinking their solution just had to be better and not understanding how anyone could possibly choose the other language).

I understand exactly how http/html works under the hood and I know how to use webforms to send data to and from the server/client. From this, I use webforms to deliver that html and I don't use it to hide how that delivery occurs. To make the assumption that everyone who uses webforms thinks like how a desktop developer would write a program is naive.

I think of webforms as a very simple engine, and in reality think of my Page probably the same as how you think of a View but with the added benefit of being able to interact with the html via events prior to it being sent to the user. Someone makes a request to my server, my events fire in a certain order and produce the required html, webforms gathers this html and then delivers it (bear in mind that I only ever use the server controls that I have control over the output of). That is essentially how all web applications work whether you use MVC or not. I'm sure some people get all mixed up with server side events, the order in which they occur etc but in reality it's very simple. You make a request, I (the server) execute x then y which generates the html and delivers it back.

And, to address some of your points above, it's also possible to turn it on it's head for MVC to look at the negatives:

(1) extensible - MVC makes it difficult to package up user controls to distribute throughout multiple projects. With webforms, you just include the server control.
(2) simple - Not so simple at all, in fact I'd say more complex. Try the "Hello World" example in both webforms and MVC and see what requires more logic, coding and setup time for new developers. In fact, just look at the number of 3rd part external frameworks you have to know in one of your projects just to send/retrieve data from a database to a web client.
(3) works with the concepts of http - getting data out of the request is more complicated. You can't just reference the id of the control you created and instead have to go through the ViewData.
(4) solves a single problem - webforms (the page) isn't concerned with how you retrive your data, or at least it shouldn't be so if you are doing that then you're doing something wrong. I can't see a negative here for Views or Pages, they are simply gathering the html prior to it being sent.

To be honest, I hesitated even bothering to write that last section and probably shouldn't have. It's pointless. I just wanted to show that there are negatives too (on both sides) but equally, used correctly, they both work brilliantly. For some people (i.e. like Karl), this isn't enough and for reasons unknown to me, because he prefers MVC that means he must try to belittle people who have chosen an alternative route. I'm happy that people choose their own path and it really doesn't matter to me which path they decide as long as it works best for them.

Mark,

Darlington Web Design
Experts, Information, Ideas & Knowledge
ASP.NET Tips & Tricks

 

[jmeckley]

Mark you bring up some good points. At first I wanted to respond to each point, but realized that's just throwing fuel on the fire and wouldn't be that productive. I also had a article in my reader this morning which I found thought provoking and I'm interested in what you response would be.

before I get to that though I did want to respond to one comment you made

You make the assumption that people who use webforms think of it like a desktop application.

It's not that developers think of webforms as a desktop application. Rather, MS designed this paradigm because a large portion of there clients were currently designing desktop UI's when .net was fist released. So it made sense to provide an environment similar to that to help migrate desktop development to web development.
Another reason, which is mentioned in the link below, is at the time webforms was first introduced each client (browsers) varied so much and the DOM/JS was not understood that the decision was made to move this functionality to server via server side controls.

this makes perfect sense to me, as I was one of those developers who didn't understand DOM/JS. I avoided it. But with the advent of better standards among browsers and js libraries, I was no longer restricted by what webforms could offer.

here is the article by Ian Cooper MVC or WebForms: It's more about client side vs server side
A majority of the article breaks down the differences between MVC and Webforms from a technical POV. But the article ends with this: The future of web development is on the client and this will come down to SliverLight vs JavaScript. In this scenario the server can simply respond to requests as servicing layer. MVC does this very well with a simple API.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[ca8msm]

MS designed this paradigm because a large portion of there clients were currently designing desktop UI's when .net was fist released

That's probably true. It makes sense for them to increase their development base by making it easier for people to make the transition if that is the type of developer they are trying to attract. Things like the data source controls, the drag/drop formviews etc make it easy for people who don't understand what is happening to create a web based application without having any HTML knowledge. And I think this is where you are coming from with your debate.

However, and I don't know if I am just in the minority here, but they are the type of things that I avoid like the plague in webforms. Most of my pages don't use viewstate, I only use server controls that I can control the html output of, and I use client side frameworks (mainly JQuery) to interact with that html. I'd bet that probably 95%-99% of my outputted html is exactly the same as if I were to use MVC to create it. So, to me, I can do all of what MVC could with webforms and the only real problem that webforms cause me is the client manipulation due to the auto generated id's of the elements. For now, it's an easy workaround by just using the class name to target them, and in ASP.NET 4.0 I will be able to specify them myself.

Personally, I have no problems using an MVC pattern, and just like my ORM experiment (thread855-1585222) we will no doubt use it for a project in the future, but from my exposure to it I really don't think I/we will see much benefit. That may not be the case for other developers in other environments, but for us I think that webforms is the right choice (and a choice is exactly what I think it is, not a legacy like that article suggests).

Mark,

Darlington Web Design
Experts, Information, Ideas & Knowledge
ASP.NET Tips & Tricks

 

[jmeckley]

Things like the data source controls, the drag/drop formviews etc make it easy for people who don't understand what is happening to create a web based application without having any HTML knowledge.

And this is where I think webforms falls short. because of these features I think novice webform developers back themselves into a corner without even realizing it. The most common example we encounter is "how do I inject logic into my datasource control?".

if you think about the default webforms settings (which I believe most developers use) it sets up a medium/large project for failure. The defaults being client viewstate and drag/drop controls.

You/your team are proof that quality applications can be designed with webforms, however the friction (nonstandard approach) that is required to get there goes against most of how webforms was designed.

I would be interested to see one of your webforms in comparison with a "typical" webform.
are you writing raw html and injecting the dynamic values, where necessary or are you using the simple server input controls and binding data?
if you disable viewstate, are your Pages no longer concerned about postback?
would you manage layout via CSS and Style attributes on the client or control properties?
can you put multiple html forms on a single webpage since Webforms works with exactly 1 html form?
Webforms validates each request to prevent malicious attacks and this can be a problem with cascading drop down lists and dynamic (ajax delivered) content. Are you heavily leveraging ajax, if so how do you manage that since webforms validates viewstate/postbacks?
how do you resolve dependencies within the Page object? Static factories? object instantiation? Dependency injection?
A lot of questions I know. I'm curious because it sounds like you are using Webforms in a manner which I was never aware was even possible or ran into too much resistance.


Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[ca8msm]

And this is where I think webforms falls short. because of these features I think novice webform developers back themselves into a corner without even realizing it. The most common example we encounter is "how do I inject logic into my datasource control?".

I don't think this is a failing of webforms, I think it's a failing of how webforms is marketed.

And a few answers to your questions...

I would be interested to see one of your webforms in comparison with a "typical" webform.
are you writing raw html and injecting the dynamic values, where necessary or are you using the simple server input controls and binding data?
if you disable viewstate, are your Pages no longer concerned about postback?

I'm not so sure that my webforms are entirely different in principle to anyone else's, it's purely that I'm strict on what controls can be used and how they can be used. My thinking is always driven to what the rendered source will produce which may be where the difference lies.

As for the comments about data and postbacks, I still use simple server controls you just have to actually understand when and where viewstate is actually used (which I really think a lot of people don't and it sometimes gets bad press because of this). For example, take this very simple page with viewstate turned off:

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default28.aspx.vb" Inherits="Default28" [b]EnableViewState="false"[/b] %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "[URL unfurl="true"]http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">[/URL]

<html xmlns="[URL unfurl="true"]http://www.w3.org/1999/xhtml">[/URL]
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
        <asp:Button ID="Button1" runat="server" Text="Button" />
    </div>
    </form>
</body>
</html>

Partial Class Default28
    Inherits System.Web.UI.Page

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        If Not Page.IsPostBack Then
            TextBox1.Text = "Starting Value"
        End If
    End Sub

    Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
        Response.Write(TextBox1.Text)
    End Sub
End Class

A common misconception is that the page wouldn't remember what you typed into the textbox because of the EnableViewState="false" declaration. However, if you run it you will see that it does.

Obviously that is very simplistic but I'm sure you get what I am trying to explain.

would you manage layout via CSS and Style attributes on the client or control properties?

I control all layout and design via CSS. All I use the IDE for is for manually writing the html and I never use the properties or design windows in VS.

can you put multiple html forms on a single webpage since Webforms works with exactly 1 html form?

There's a slight error in that statement, webforms only allows one form with the runat="server" tag. I can have as many forms on the one page as I like as long as I abide by that rule (and the html rules of no nested forms etc).

Webforms validates each request to prevent malicious attacks and this can be a problem with cascading drop down lists and dynamic (ajax delivered) content. Are you heavily leveraging ajax, if so how do you manage that since webforms validates viewstate/postbacks?

That's where the EnableEventValidation="false" declaration comes into play. If I need to validate the request I will do so myself which is I guess what other frameworks force you to do. So, although in my case I do use ajax (I wouldn't say heavily though), I can't say I've noticed any glaring problems using it.

how do you resolve dependencies within the Page object? Static factories? object instantiation? Dependency injection?

I don't understand what you are asking, can you explain in more detail?

Mark,

Darlington Web Design
Experts, Information, Ideas & Knowledge
ASP.NET Tips & Tricks

 

[jmeckley]

I don't think this is a failing of webforms, I think it's a failing of how webforms is marketed.

This too could be the crux of the issue. Although if you think about controls like [X]DataSource, Menu and Wizard. Webforms doesn't encourage clean code. DataSource has nothing to do with html and you have an issue with separation of concerns. Menu and Wizard produce horrendous html with all kinds of nested tables. Adding CCS and javascript become a pain point. This can all be avoided if you don't use them, but that like sending a kid into a candy store with $20 saying "don't buy any candy".

I wasn't aware that a webform could have more than 1 html form. It makes sense as the webform isn't aware of the html, only the server controls. Say we have a webform with 1 server form and a 2nd standard html form element. when you submit the 2nd html form I assume this is consumed by the Webforms framework as an initial request (postback = false) to a different webform?

this still seems more complex that letting each request be it's own atomic request (the concept of postback).

how do you resolve dependencies within the Page object? Static factories? object instantiation? Dependency injection?

I don't understand what you are asking, can you explain in more detail?

within your Page subclass you would need dependencies. Say a service to run calculation and a repository to get data from the database. here is a crude example.

class Repository
{
   public DataTable GetRecords()
   {
       //query database and return records
   }
}
class Service
{
   public void Calculate(DataRow row)
   {
       //run calculations against the row
   }
}
class MyPage : Page
{
   public override void OnLoad(EventArgs e)
   {
      base.OnLoad(e);
      if(IsPostback) return;

      [COLOR=green]//how do you get an instance of Repository?[/color]
      var records = repository.GetRecords();
      foreach(var record in records)
      {
      [COLOR=green]//how do you get an instance of Service?[/color]
          service.Calculate(row);
      }
      AControl.DataSource = records;
      Page.DataBind();
   }
}

I figure there are 3 approaches.
1. instantiate the class directory in the code behind

var repository = new Repository();

2. use static factory class.

public class RepostoryFactory
{
    public static Repostory Create()
    {
        return new Repository();
    }
}

var repository = RepostoryFactory.Create();

or method

class Repository
{
   public static readonly Repository Instance = new Repository();

   public DataTable GetRecords()
   {
       //query database and return records
   }
}

var repostiory = Repository.Instance;

3. Use a Inversion of Control container (Ninject, Unity, Windsor, Structure.Map, etc.)

//create the container and register the repository in the application startup. apply container to a static object. then you can resolve.
var repository = StaticReferenceToIocContainer.Resolve<Repository>();

With any of the MVC containers you do not need default constructors. Some require you to override the default controller factory. but once that's done you can inject dependencies.

public class Controller
{
     public Controller(Repository r, Service s)
     {
     }
}

by utilizing dependency injection the controller (presenter, or more generally the service) is simpler. It only needs to use the dependencies. it's not concerned with managing the scope of the dependencies. Because, ctor or property injection doesn't exist in webforms* I would need to resolve those dependencies myself using one of the approaches I described above. That's more infrastructure functionality I would need to create. I'd rather spend my time focusing on the business functionality.

::foot note::
*There is 1 framework I found which allows you to inject dependencies into a webform. Rhino.Igloo. It's part of Ayende's suite of open source projects, but it's not actively maintained at the moment. I used this on 1 project, but I didn't like the outcome. It felt like a compromise between Weforms and MVC.
::end foot note::

another pain point I found with webforms is tag soup in the markup, but then every html engine suffers this sloppiness in one form or another. An advantage of MVC frameworks is they allow you to choose a different html engine if you desire. You can even utilize multiple view engines if necessary. This creates an environment to design better view engines. I think Spark is the leader in this forefront at the moment. It reminds me of PHP's Smarty template engine.

Reflecting on the debate of Webforms vs. MVC. I think the deciding factor may simply be options (extensibility). Do you need/want the ability to change functionality? If so, MVC would be the better choice. If you don't Webforms is an option. Then comes which API do you prefer? Personally I find MVC API's much simpler, with fewer moving parts.

thanks for the insight Mark.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[ca8msm]

This too could be the crux of the issue. Although if you think about controls like [X]DataSource, Menu and Wizard. Webforms doesn't encourage clean code. DataSource has nothing to do with html and you have an issue with separation of concerns. Menu and Wizard produce horrendous html with all kinds of nested tables. Adding CCS and javascript become a pain point. This can all be avoided if you don't use them, but that like sending a kid into a candy store with $20 saying "don't buy any candy".

I share the same thoughts as you here (is that a 1st? ) as I think it's marketed badly. I know I can develop good clean systems using them, so why don't they promote them like that? I honestly feel that if they had that a much lower percentage of people would be slating them now.

For your dependencies, you're right I often use method #1 or #2 (I don't use an IoC but as I understand it pretty much all MVC projects use one). However, I could probably replicate your injection by using a base class for all pages and injecting the objects in from each page. In fact, that's probably an approach I should be using.

One of the issues that I have from an MVC approach is whilst it is often said that MVC is a more natural, simplistic approach, it often looks to assume you have a good understanding of other frameworks. Take for example one of the MVC books I bought (I won't name it as it's not meant to be a bad review of any particular book), before they actually take you through any of the basics they say you will need:

1. A mocking library
2. An IoC
3. An O/RM
4. A unit testing library

Now, imagine what it is like to be told that for complete beginners. Not only will they probably not even know what some of those things are, they are expected to have researched and made a decision on which framework to the best option for them before they can even make a start. It could just be this particular book that takes this approach, but I don't think it is as most MVC articles I read assume you already have knowledge of and use the above.

This is my concern (much like I had with the webforms marketing) that when people talk about MVC, the solutions they talk about often look confusing to the end user who may not know how to use these frameworks (I think I can probably include myself in this category sometimes as well). In fact, I've very rarely come across any good, simple MVC articles that show simple database access without using some kind of 3rd party framework (I'm not saying they don't exist, I just think they are in the minority).

Mark,

Darlington Web Design
Experts, Information, Ideas & Knowledge
ASP.NET Tips & Tricks

 

[Turkbear]

Hi,
at least to me, these seemed fairly easy to understand and follow.

http://www.asp.net/learn/mvc/#MVC_Overview

To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[whosrdaddy]

Hi,

I recently started to use C# for web development. So I can give you my POV regarding this debate.
A little about me:
I have 20+ years experience building fat clients/services in a Borland/Codegear/Embarcadero Delphi envorinment.
My employer is seeing more and more oportunities in web development, so that's the reason I'm converting to the .NET world.
I have a strong background in VB/VBA so I started of exploring VB.NET and Web Forms. Created a simple website for a customer, and that project was delivered smoothly.
Because Webforms gave me all the concepts that I know from the UI world (events, controls, ...).
I know a little html, but I really don't like to write it. Played around with C# and really liked the "cleaner" syntax.
On my daily reads of the C# tek-tips forum, I notice always one user crying foul(yes Jason, that is you ) about some other guy's sloppy code and that we must read websites like codebetter.com and lostechies.
So I went to visit those places, read about design patterns (and was pleasantly suprised I was using a lot of these patterns in Delphi).
Then I stumbled on some nice blogs with nice samples about MVC.
I didn't knew a thing about MVC about six months ago.
Today I am developping a new website for an internal project and I decided to go MVC.
These are the technologies I am learning at the moment:

- C#
- ASP.NET (MVC)
- Some more advanced HTML
- Spark ViewEngine (I really LIKE this engine)
-> Spark is one of the main reason I went the MVC route (Thanks Jason for mentioning Spark in the forum posts)
With spark (partials) I can keep the views simple and tiny (Now I really like writing HTML for these views)
- jQuery
- Windsor IOC
- (Fluent) NHibernate
- Automapper
- NUnit (I use DUnit on the Delphi side, so not really new)
- Still looking for a mocking library, though I find some sources on the NET that oppose mocking.

You can see that the list is very long and I can assure you that the start was slow and frustrating. For some time now, I have finally understood the main concepts of these technologies and I'm starting getting comfortable at using them.

So from my experience, you guys are both correct.
I look at both sides like this:
Webforms = RAD web development (geared towards UI devs),
best suited for small projects.
MVC = This technology "forces" the developer to think about his code and encourages to write cleaner code (at least in my case it did )
I also believe it is the logical choice for bigger projects and I'm pretty sure this infrastructure is much easier to maintain.

So there you have it, a viewpoint from a noob webdeveloper

Cheers,
Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[jmeckley]

Daddy, thanks for sharing your experience with webforms and MVC. I think is it's great to see how other developers are using the various technologies in web development.

How do you think your experience would have been different if webforms did not exist when you first entered the web development environment?

Side note on mocking frameworks:
Rhino.Mocks is the most popular and is open source with a very active community. so long as the class is not sealed and the member is public virtual/abstract you can mock it. Dynamic Proxy makes this possible.

If you need to mock sealed, static, or non-virtual members have a look at TypeMock($). It can mock these types of members/classes by using code weaving. Some devs do not like that feature because it can drive poor design. On the other hand you can test code which was previously untestable.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259

 

[whosrdaddy]

How do you think your experience would have been different if webforms did not exist when you first entered the web development environment?

Basically MVC introduced me to a whole new world, so yes there would have been a difference if I had known this from the beginning...

/Daddy


-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[kss444]

Here is an article that describes some of the advantages using MVC and some Web forms based.

http://www.asp.net/learn/mvc/tutorial-01-cs.aspx

need to scroll down the page.

Because of this thread, I have started to look into MVC and what it has to offer me and my company.

So far I find it to be just another n-tier architecture.

But right now I am just teaching myself MVC.

Ordinary Programmer

 

[jmeckley]

kss444, the link you provided is a good introduction at a very high level.

So far I find it to be just another n-tier architecture.

But right now I am just teaching myself MVC.

in very general terms it is just another n-tier architecture frameworks are designed to solve a piece of the puzzle when designing a system. any given framework (1) is used in conjunction with others to create a complete system.

In this case the decision is "how do you want to control flow of information to the html template: webforms, or mvc?". if mvc the next quetions is "which MVC framework do I want to use?". Depending on the needs of the system and how to prefer to structure your applications will play a significant role in selecting a framework to deliver content over the web.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190
faq732-7259