1. Web pages is some kind of "view" sitting on top of MVC?
2. I see that there is more than one MVC "version", is that the case for "Web forms" as well or is there only "one" "Web forms"?
3. If I use MVC "version 3", when "version 4" comes out, do I need to rewrite a lot of stuff? I know MVC 4 is not out ( or 5, not sure ) but how was it from version 1&2 into version 3. Lots of change and rewrite to make it "version 3"?
4. Is MVC just a "way of writing applications" or is it a specially made "tool" so to speak?
5. Which one of those from the coding side, "looks more like" PHP?
6. Which one do you personally prefer, and why?

Sorry if my questions seem rather stupid but I am almost completely ignorant regarding ASP.NET.

Thanks!

2. Web forms is the 'old' asp.net technology, their versions distributed with the .Net framework. MVC is not part of the .Net framework. Web pages are just dynamic html with no serverside controls and no MVC.

3. Often you can convert the solution, do some small changes and recompile. Unless you have done some seriously freaky stuff.

4. It's a pattern, wich seperates logic from UI. It provides you with a unit testable way of writing asp.net application, while the designer can do his magic in the frontend pages.

5. Web pages.

6. MVC, it's the shizzle. No more page lifecycle, web forms are too loose for enterprise development, good for a hobby or small pet project, but not for 'real' apps.

Cheers!

There is an article here that might be helpful, except for this one aspect:

"Please note that this MVC discussion is within the context of desktop applications; Web applications are another story and beyond the scope of this article."

http://msdn.microsoft.com/en-us/magazine/hh580734.aspx

2 hours ago, WhatDoYouMean wrote

I have read the descriptions and features of them in www.asp.net website. Still confused about "Web pages" vs "Web forms" vs "MVC".

1. Web pages is some kind of "view" sitting on top of MVC?
2. I see that there is more than one MVC "version", is that the case for "Web forms" as well or is there only "one" "Web forms"?
3. If I use MVC "version 3", when "version 4" comes out, do I need to rewrite a lot of stuff? I know MVC 4 is not out ( or 5, not sure ) but how was it from version 1&2 into version 3. Lots of change and rewrite to make it "version 3"?
4. Is MVC just a "way of writing applications" or is it a specially made "tool" so to speak?
5. Which one of those from the coding side, "looks more like" PHP?
6. Which one do you personally prefer, and why?

Sorry if my questions seem rather stupid but I am almost completely ignorant regarding ASP.NET.

Thanks!

1) No. You can use Web Pages completely by itself.

2) Web Form usually does not evolve because it is pretty old technology. What it can evolve is already been done, sort of.

3) I cannot comment on that, but, shouldn't be too bad.

4) MVC is a pattern, but, yeah, you can say it is a template / tool that MS provides that follows the MVC pattern.

5) Razor, it doesn't matter you use Web Pages or MVC4, you can use Razor, which is better than PHP to indicate server side code.

6) Razor + Web Pages. Honestly MVC has really high learning curve and it is quite overkill in many cases. Web Pages is a lot simpler. Razor + Web Pages = simple dynamic HTML generation and program in C# at server side. If you want to pass model around, you can always write the .cs classes and pass those around between method parameters. MVC seem to be able to pass model around among pages? (I am not really familiar with MVC, just trying the tutorial a little). The problem with MVC is you spam 3 files for a page, but, sometimes you are only doing simple stuff that doesn't really need to spam 3 files all over the places.

6.5) You want to use MVC in co-op environment, where the view can be made by different person. If you are the only person, or you think View should be modified at CSS level, then, Web Pages is more suitable.

7) Extra note, try this fun Razor code

@{

@:@myvariable

}

This is a funny way to write value of myvariable within a @{} code block. It is shorter than wrapping the variable with <text></text>.

8) Reminder, you can use Razor on MVC. Web Pages is just a library that you can use to access URL data, form data, connect to SQLCE and etc. You can actually use the same library in MVC as well.

I have been looking all over the place for good answers.

Thank you very much!

yw

all the elite ASP.Net gurus hang out in the coffeehouse you know

For specific technical questions, use the TechOff forums, for questions like the above you can post them in the CoffeeHouse.

1 hour ago, Maddus Mattus wrote

@WhatDoYouMean:

yw

all the elite ASP.Net gurus hang out in the coffeehouse you know

Where do the App, app, app (god I love that word app ) gurus hang out?

In their parent's basements ofcourse!

2 hours ago, Maddus Mattus wrote

@Proton2:

In their parent's basements ofcourse!

LOL

The .Net framework houses a lot of technologies out of the box, like WPF, Windows Forms and ASP.Net. But there are also a lot of stuff that gets built outside the framework, Silverlight, MVC, etc.

Big advantage is that they can have their own release cycle, also a disadvantage but I think the pros outweigh the cons.

Using MVC, it's like, well it's hard to explain. There is no control and I don't know what the heck is going on in the code.

Specially when in the Views, code and HTML is still "mixed up" I don't see the advantage of MVC at all so far. Why can't I just make a regular Class in a .CS file and put my code in there?

Or am I totally off now?

IMO, it's far easier to understand how the plumbing for MVC works than it is to understand how WebForms work.

As far as "lock-in" is concerned, you should be more concerned about lock-in using WebForms. WebForms depends heavily on ASP.NET web controls. With MVC using Razor syntax, you use standard HTML mark-up. It's far more like PHP than WebForms mark-up.

It even handles the routing and stuff as you mention. Zero control. It feels like that thing Lightroom or what it was called. ( Lightswitch )

Regarding WebForms, as long as I don't use their specific controls, I should be fine, no? I mean, as long as I don't use the runat="server" thingy?

You can have a MVC site with completely no MVC inside you know.

MVC is just a template. I don't know how to apply the template after you choose Web Pages route, but, you can easily start from MVC template and don't use any MVC pattern at all, just plain .cshtml file with everything inside (your logic and html generation and redirect). And in case you wants to use MVC, your site can use MVC.

• You can write .cs file.
• Just create a folder called App_Code and put your .cs inside. All .cs has to be under App_Code.
• You can also write .cshtml as class object, but, this, you can place anywhere in the site.
• All .cshtml files are converted to class at runtime, so, the performance is the same.

I suggest you to use Web Pages for now to get a feel of how Razor syntax works and how you can use .cs in your site. This is why I don't recommend MVC for beginners, it is additional learning curve.

Download WebMatrix and start from there. The core of Razor pages are much simplier to use.

Also REMEMEBR!!!

Have this in your web.config 

<system.web>

<compilationtargetFramework="4.0"debug="true"/>

</system.web>

VS Express said it is 4.0 in the GUI, but, sometimes it turns to 3.0 if you don't specify it.

Or is Razor only usable in WebMatrix?

Sorry if I sound stupid but totally new to this. I am trying to keep out as much "extra add-ons" as possible, however.

ASP.NET was originally mean to be deployed as a single piece as part of the .NET framework. However, since they are branching out to different stacks such as MVC, I think you will eventually see Web Forms seperated from System.Web and deployed as an add-on stack just like MVC.

Razor is independant from MVC and WebMatrix. Razor is the name of the markup that both of them can use. It's just text, you don't need anything special, and you can write it in notepad if you want.

There shouldn't be any worry about "extra add-ons" since MVC can be deployed as a self contained unit. Just make sure the server has .NET4 and use "Add Deployable Dependencies" and MVC will work just fine.

Recommended reading: http://www.asp.net/mvc

I mean, I like the way MVC separates stuff but I feel unease to give too much control to a Framework.

Would that be a good way?

MVC is built on the principle of control, so you can replace the various pieces with anything you want. What kind of control are you worried about losing? Unless you write your own stack from scratch, you have to trust somebody else's code at some point.

2 hours ago, WhatDoYouMean wrote

I am pondering this: I use MVC but I will initiate the "Models" manually and use Requests and such instead of letting it handling "everything". This way, I can "move away" from it in case of let's say "emergency".

I mean, I like the way MVC separates stuff but I feel unease to give too much control to a Framework.

Would that be a good way?

What bits are you concerned about here? Model binding? What's the actual concern? What is your emergency scenario?

Other than that, The whole separated classes "Models", Controls and Views are really nice.

Still newbie though.

ps. I mean, it's nice that it handles stuff "automagically" but I feel very "locked in" that way because once the project grows and I get use to it, there is no way it can be "moved" to say PHP or something else in case of "emergency".

The thing is, the more you stay within the framework, the more automatic a lot of stuff is that you would have to worry about otherwise. I would look at more tutorials before you decide to jump ship on conventions, etc. Obviously, you should break out of it when the solution is something incredibly long winded, confusing, impractical. But do give it some thought.

2 minutes ago, WhatDoYouMean wrote

Well, I didn't like the whole handling of Requests. It passes the Model "automagically". In the demo, I didn't even see anywhere, where it "initiated" as in "new bla();" so it felt very "Lightswitchy" if you know what I mean.

Which is a good thing, honest You can control model binding with custom binders, but frankly it's rare you'll need too.You can limit the fields that get bound to models (and you shoud) with [Bind(Include)] or [Bind(Exclude)].

However I've not saying use your data models for binding (or EF models, or whatever). I use view models to limit what a view gets to what the view needs.

<% using (Html.BeginForm()) { %>                   

<%: Html.LabelFor(m => m.OldPassword) %>

I mean, what the heck is that? and it gets handled "automagically" in the Controller class. No fetching of data via the "Request" etc.

That's why I feel the unease of "lightswitch" in this.

Then again, why not just use "Request"? Isn't it easier and more stright forward specially if you want to be able to "leave" the platform and not lock yourself into this too much?

36 seconds ago, WhatDoYouMean wrote

Here is an example:

<% using (Html.BeginForm()) { %>                   

<%: Html.LabelFor(m => m.OldPassword) %>

I mean, what the heck is that? and it gets handled "automagically" in the Controller class. No fetching of data via the "Request" etc.

That's why I feel the unease of "lightswitch" in this.

That begins a form, then displays an HTML <label> for the old password field/property in the model.

There is no concept of Request in views.

19 seconds ago, WhatDoYouMean wrote

Any sources where I can read up on how to make a custom modelbinder?

Then again, why not just use "Request"? Isn't it easier and more stright forward specially if you want to be able to "leave" the platform and not lock yourself into this too much?

No. Your views don't need a request. You don't need to parse requests into lists yourself? Why reinvent the wheel? If you want to leave the platform, well, you're going to have to rewrite all the request/response code anyway. False economy.

But, if you wrote code in tiers, and had a business layer + data layer containing all of your business objects (reference them in your models), treating the MVC application as just a client app that consumes your business objects, then you get the flexibility to "move" when you need to. Just construct a new "web forms" application that consumes the layers you had before.

There is a personal line there which no corporation is allowed to cross.

ps. I DO like Microsoft technologies. Been a fan for years. 

There's no need to manually parse requests, and it's not magic. If your parameter is named 'x', then ~/controller/action/x is going to work. With PHP, you may have to get fiddly with every little detail, but MVC allows you to set up some conventions that are as simple or complex as you'd like, and it wires things up based on the conventions.

I create a separate asp.net project and use a say .ASHX to puke out XML-data then I manage that XML-data into my MVC project and just "show it". All business logic and such will be done in that separate project.

Is that a bad thing? Any recommendation or is it a good way to do it?

WhatDoYouMean said:

Just for the record, I DO like this whole MVC thing but I dislike the lock-in potential of it and having seen where Microsoft is headed with Windows 8,

If you work in Ruby on Rails, your code will not automatically work if you move it into a PHP environment. You'll have to rewrite it all. Same thing vice versa. I don't understand why you think this "lock-in" potential is specific to ASP.NET MVC?

It's exactly the same when we do choose a business to take care of the IT or out networking systems. You don't want to get too much locked-in in case you want to switch to someone else.

It's just a way of having the door half-open, just pure business thinking.

43 seconds ago, WhatDoYouMean wrote

It's just a way of having the door half-open, just pure business thinking.

But if you're constantly leaving the door open, you're never really closing it, which can let in a draft and raise your heating bills in the long run. By not committing entirely, you're not going to be very productive and you might just waste a lot of time (and money) investing in ways to keep your platform so flexible to support your various jumps from ship to ship.

Though, I'm not one to tell you how to run your business - it's your call in the end.

I know I can't just copy/paste code from C# to PHP but the general building of it must be a way so it's "clear" what's going on and all automations should be handled by "us" and not some weird automagical function.

For example the MVC Demo, I see a ready made "ChangePassword" function. What the heck? What business would want to use that and get locked-in?

I find the MVC demo very "un-codey". Hard to explain.

The only aspect I like is the separation but we don't really need Microsoft MVC to separate like that.

11 minutes ago, WhatDoYouMean wrote

@blowdart: Parsing requests is exactly what I need to do because in case I need to move this thing out of MVC into PHP, it would make it MUCH harder to understand the code because frankly, there isn't much "coding" going on in that Demo atleast.

OK so you are going to write code in C# to parse a request object. Code that wouldn't work anyway if you went to PHP ... umm ...

31 seconds ago, WhatDoYouMean wrote

@kettch: Lightswitch isn't programming. It's "File maker".

Actually, I have a LightSwitch project that has a few thousand lines of highly portable business logic. Contrary to what I said before, I could copy and paste that logic into another .NET platform and it would still work the same with only minor tweaks. LightSwitch is just a quick way to build the UI and data access. Having used FileMaker in the past, there is no comparison between the two.

LightSwitch, MVC's "magic", all if it has a place. You want to use the right tools for the job, but make sure to use the tool as it's intended. For me, these tools make it easier and faster for people to produce production applications. It's a waste of time and therefore a waste of money to constantly be re-inventing the wheel for every project.

Just example: From Pascal to C++ to VB to "Delphi" to C# to what not... see a pattern?

Imagine if my code was lock-in so much that I couldn't move it from Delphi to C# because Delphi would do so much invisible automagical things that there wouldn't be much visible code at all. All requests get handled automatically. That's all fine and dandy and I DO like it but from a pure business point of view, that is very bad business.

The same way we left Delphi to .NET, I'm sure in 5-10 years we'll move to something else, so the less "invisible magic", the better.

@kettch: Emergency means, well if you read my other thread you will know what I mean. We are moving away from developing for Windows Clients, THAT is an emergency.

I don't see how it's an emergency. If your client applications are well written, a lot of the code should be easily portable. Even moving it to back-end services would allow the applications to continue to working, while providing access to other web applications built on whatever platform you want.

I know I can't just copy/paste code from C# to PHP but the general building of it must be a way so it's "clear" what's going on and all automations should be handled by "us" and not some weird automagical function.

It's not weird or unclear, it's very simple and it's right there in the documentation.

For example the MVC Demo, I see a ready made "ChangePassword" function. What the heck? What business would want to use that and get locked-in?

It's a demo. Somebody already built an account controller that handles those functions, and everything is there for you to modify as you please.

I find the MVC demo very "un-codey". Hard to explain.

There's actually a lot of code in there.

The only aspect I like is the separation but we don't really need Microsoft MVC to separate like that.

No, you don't need them to do it. However, you'd be hard pressed to find a cleaner and more flexible implementation of the MVC pattern.

Like, if you really need to keep a way out, you'd might as well just write the majority of your stack in assembly (but then, you'd have to prepare for ARM instruction set in case x86 somehow dies off).

Anyway, you could just write an asp.net web service and then write an asp.net mvc app to consume the web service. I think that's a fair way to do it unless anyone else thinks that's a bad idea.

A business must be able to dictate conditions as much as possible not be dictated conditions hence, one must be worried about lock-ins.

I'm not saying MVC is all evil, don't use it. But I think one should be a little careful. Candy is good but bad for the teeth in the long run.

2 minutes ago, WhatDoYouMean wrote

@kettch:"I could copy and paste that logic into another .NET platform and it would still work" <- There you have it. Could you convert that into Delphi or PHP with such ease? I think not. Which makes it a "dangerous" business decision.

Yes, I could convert it to Delphi or PHP with ease. I don't get it. Do you have some magical tool that lets you paste in Delphi and get out perfect PHP?

Imagine if my code was lock-in so much that I couldn't move it from Delphi to C# because Delphi would do so much invisible automagical things that there wouldn't be much visible code at all. All requests get handled automatically. That's all fine and dandy and I DO like it but from a pure business point of view, that is very bad business.

Funny you say that. Delphi pioneered some of the first drag and drop data access components that used all kinds of "invisible magic".

Haha YES! and here is the point: We NEVER used them.

ps. When Delphi kind'a "died", we just moved to .NET. Was able to rewrite the controls very fast because they weren't some automagical control built-into Delphi.

3 minutes ago, WhatDoYouMean wrote

@kettch: "Funny you say that. Delphi pioneered some of the first drag and drop data access components that used all kinds of "invisible magic"."

Haha YES! and here is the point: We NEVER used them.

ps. When Delphi kind'a "died", we just moved to .NET. Was able to rewrite the controls very fast because they weren't some automagical control built-into Delphi.

When I'm porting an application, whether it's from something like PHP, or chicken scratches on the floor, I hardly ever look at the data access code. That kind of stuff is guaranteed to change between platforms, so it's useless. All I need to know about an application is that it manipulates data 'x'. If you've got something in the data access code that needs to be specifically ported, then you are doing it wrong.

1 minute ago, kettch wrote

All I need to know about an application is that it manipulates data 'x'. If you've got something in the data access code that needs to be specifically ported, then you are doing it wrong.

+1

Also, if you have your design documents/schema, then you should be able to reconstruct the entire application in a different framework to get identical behavior/functionality.

Ruby on Rails and other popular frameworks use MVC as well - including model binding, views, routing, etc. So if you're worried about future proofing and lock-in, MVC is likely the best thing you could be doing.

1 hour ago, WhatDoYouMean wrote

Any sources where I can read up on how to make a custom modelbinder?

Then again, why not just use "Request"? Isn't it easier and more stright forward specially if you want to be able to "leave" the platform and not lock yourself into this too much?

Have you looked at web matrix? (I haven't myself, but one of the PMs over there says it's pretty much like his, no binding, no models, very php like)

At that point you are actually providing a valuable service by making sure that there is plenty of material for TDWTF.

11 minutes ago, davewill wrote

He/She is simply trying to pick the best fit for today while also hedging for the future.

I hope he/she isn't planning on ever getting married

Great thread, by the way, friends.

-Hanselman

7 hours ago, davewill wrote

WhatDoYouMean is trying to strike a balance between what is 100% known today and what is 100% not known in the future.  He/She is simply trying to pick the best fit for today while also hedging for the future.

You said it better than I could have ever done it.

What you're saying sounds a lot like this:

"Oh I won't use ADO.NET to access my data. I'll write directly to the OLE DB driver, because ADO.NET might not be in the FancyPants Framework released in 2020."

Why reinvent the wheel? Just use what's there and assume that the next platform you move to will have something similar. The productivity gains far outweigh the loss in flexibility.

Like I said, you don't need to learn ASP.net  MVC right now. Stay with Web Pages for now. I cannot really help on how the model is created and passed in the MVC, it is quite magical indeed. Also don't use <%> anymore. Go with razor. I don't know if you need extra plugin for razor or not. I have both WebMatrix and VSExpress, and VSExpress works.

Stay with Web Pages, because that's what you are looking for.

10 hours ago, WhatDoYouMean wrote

*snip*

You said it better than I could have ever done it.

OK so, go with an SOA architecture. Take the best of what's known today.

1) Database access code these days is generally automated by ORMs and generated for you at the press of a button. .NET has ORMs, Java has ORMs, Rails has ORMs, even PHP has ORMs and the implementation of the Active Record pattern (although there's an argument that active record is a silly pattern anyway). So database access code doesn't matter.

2) If database access code doesn't matter then you could use that as your model. It's not idea, it probably passes too much information to the web pages that they don't need though, the idea would be having a layer that turns the database models into the information that each part of your application actually needs - view models.

3) Creation of view models from models is usually a simple object mapping, pretty easy to write. .NET has projects like automapper that take care of it for you, but if you want to write the code yourself for some reason it's usually a property to property mapping done in a constructor.

4) If you want to plan for an unknown future the current trend is to just JSON to pass to layers, so your database feeds through to your application via a JSON layer. Again there's generators in the major languages to do this, or if you want, it's just writing out text from input.

So yes, you could spend 6-9 months writing this stuff yourself because you want to keep yourself in a job, or because you think you're going to migrate to something else in the future. The thing is you always migrate at some point 5 years down the line. By adopting patterns and tools that aid you and remove the need to write code you're going to make your migration easier not harder, because the tools (model binding, ORMs, etc.) all exist in the major (and most minor platforms). Plus of course they're well written and well tested, so you can have confidence they work, which, to be frank, doesn't exist for a long time when you reinvent the wheel yourself.

My smart-* marriage comment (which I borrowed from someone else, because their responses if they respond would tend to be more sane than mine ever are) still stands. Do you look at your personal relationships with the attitude of planning to get out because something better may come along in a few years? I hope not, because if you do that you aren't ever going to be happy, and you're going to spend more time looking at other options than working on and getting your current relationship/platform to work.