RE: if Employee implements IEmployee then would List be invariant to IList ?

[Paul Stovell]

To understand why:

interface IEmployee;
class Employee : IEmployee;
class Contractor : IEmployee;

var list = new List();
var ilist = (IList)list;

ilist.Add(new Employee());// Makes sense - the underlying List 
has an Add(Employee) method
ilist.Add(new Contractor());// Makes no sense - the underlying 
List has no Add(Contractor) method

So logically IList cannot be covariant. 

Paul



-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Kean
Sent: Friday, 8 April 2011 4:49 PM
To: ozDotNet
Subject: RE: if Employee implements IEmployee then would List be 
invariant to IList ?

No. IList is not assignable to IList. However, 
IEnumerable is assignable to IEnumeable.

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Arjang Assadi
Sent: Thursday, April 07, 2011 11:46 PM
To: ozDotNet
Subject: if Employee implements IEmployee then would List be 
invariant to IList ?

if Employee implements IEmployee
then is it true that : List is invariant to IList ?

Regards

Arjang

RE: Raising property changed events

[Paul Stovell]

+1. NotifyPropertyWeaver is the closest thing to "it just works", short of the 
C# team actually caring about what the language is used for beyond Fibonacci 
sequence calculators in console apps.


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Chris Walsh
Sent: Wednesday, 23 March 2011 12:59 PM
To: ozDotNet
Subject: RE: Raising property changed events

Apparently (according to Brendon Forster :)) All the cool kids are using this.

http://code.google.com/p/notifypropertyweaver/



From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Burela
Sent: Wednesday, 23 March 2011 1:57 PM
To: ozDotNet
Subject: Raising property changed events

Raising property changed events seems like something that most applications 
need to do at some stage. C#3 introduced the auto property i.e. public bool 
IsBusy { get; set; }
I am surprised that there isn't a way built into the framework to automatically 
raise changed events


Anyway, i saw this code used at a client site. it seems like a smart way to 
handle the raised event without using fragile strings that might not get 
updated when you change the property name

private bool isBusy;
public bool IsBusy
{
get { return isBusy; }
set
{
isDialogProcessing = value;

RaisePropertyChanged(System.Reflection.MethodBase.GetCurrentMethod().Name.Substring(4));
}
}


Thought I'd throw it out there. See how other people are handling property 
changed events in their own projects.
I'm sure there is an AOP way of introducing them. But all the AOP demos I have 
watched seem to increase compilation times by heaps.

-David Burela

RE: HTML vs Silverlight - comparative effort?

[Paul Stovell]

Just to add my 2c, it's not necessarily an "or" choice. You could build 90% of 
the app as a web app (which for webby-things, will be much faster - 
Silverlight/XAML has nothing on Razor/MVC/HTML/CSS). Then if you hit something 
that's difficult to do in pure HTML/JS, build that 10% in Silverlight.

Personally, given the power of JS and modern browsers, I'd find it pretty hard 
to justify using Silverlight for anything web/intranet. The only good case I've 
seen is where we some C# classes and needed to use them on the server and 
client, and there was no nice way to convert the code to JavaScript (though I 
wonder if expression trees in .NET 4.0 could have helped there). Even then, 
doing it over, having UI in HTML and using JavaScript/SL interop might have 
worked better.

Paul


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of James Chapman-Smith
Sent: Tuesday, 29 March 2011 12:32 PM
To: 'ozDotNet'
Subject: HTML vs Silverlight - comparative effort?

Hi folks,

I got asked a question today that I don't really have the experience to answer 
and was hoping someone here could help.

If I'm going to develop a new "web-based" application in HTML or Silverlight, 
what would the comparative effort be like? And really, what kind of pros & cons 
are worth evaluating?

By HTML I am thinking ASP.NET MVC, but it could be something else ".NET"-ish.

Cheers.

James.

RE: Propagate Database changes to application

[Paul Stovell]

And note that System.Data.SqlClient.SqlDependency (which uses service broker) 
is different to System.Web.Caching.SqlCacheDependency (which uses triggers and 
polling, making it kind of useless):

http://msdn.microsoft.com/en-us/library/system.web.caching.sqlcachedependency

Paul

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Paul Stovell
Sent: Tuesday, 29 March 2011 11:50 PM
To: ozDotNet
Subject: RE: Propagate Database changes to application

This is what I was talking about (I think):

http://msdn.microsoft.com/en-us/library/ms172133.aspx

Personally I'd probably just poll unless my demand load suggested notifications 
would work better.

Paul

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Paul Stovell
Sent: Tuesday, 29 March 2011 11:45 PM
To: ozDotNet
Subject: RE: Propagate Database changes to application

Correct, though once upon a time I did have an experiment that worked with 
query notifications. From memory you attach some kind of SqlDependency object 
to your SqlCommand (not the type that works with triggers - it used the same 
code as clustered views from memory).

There is a trade off either way you go. With a notification system you can end 
up "drinking from a fire hose" if the events happen too frequently under load 
(e.g., an Orders table probably isn't good for notifications). Systems that 
rely on polling tend to scale better (for example: this little thing called the 
internet) but that's a generalization.

Out of curiosity, is this something that needs to happen at the database level? 
Should more than one process really be writing to the database at once? Could 
it be done using a messaging system above the database?

Paul

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Grant Molloy
Sent: Tuesday, 29 March 2011 9:32 PM
To: ozDotNet
Subject: Re: Propagate Database changes to application

Ok..
well it looks like bindable linq only propagates changes from what it's got in 
memory already, not from changes in the database..

On Tue, Mar 29, 2011 at 9:26 PM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Hi Joseph,

I wasn't really looking at any particular single client solution..

If Paul Stovell is listening, what did you use in Bindable Linq.. I am 
downloading now to have a look, but thought you may be able to put into words 
for larger audience..

thanks


On Tue, Mar 29, 2011 at 9:59 AM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:
Re: client type - I was more wondering is it a web app? Windows app? 
Silverlight? Windows intranet app could do udp broadcast of changes from the 
server or something like that.

Sent from my iPhone

On 29/03/2011, at 8:18 AM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Thanks everyone for feedback..

Joseph,
SQL Server, yes, version either 2008 or 2008 R2.. More than likely R2, but not 
nailed down yet.
Client type is a DAL DLL.. I want the DAL to know when the data changes, and 
the client will subscribe to DAL events, and then DAL can fire off event when 
data is changed, and App can decide what to do about it.  Kind of like a 
publisher / subscriber model implementation.

I'm not 100% sure I'm going about it the right way or have the events in the 
right place (ie in the DAL)..

On Tue, Mar 29, 2011 at 1:55 AM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:
What type of client is it? Do you control the means by which data is written to 
the table? Are clients deployed to the internet or intranet? What kind of 
database are we talking about here (I assume you mean SQL Server, since you 
mention SqlDependency) but which version?

Joseph

On Mon, Mar 28, 2011 at 8:33 AM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Hi list,

I'm looking to have an application automagically update it's view of the data 
when the data in the connected database table changes.
I've seen two main ways to do this so far.
1. Poll the database every n seconds
2. Use the System.Web.Caching.SqlDependancy object.

Does anyone else know of any other better or smarter way of doing this ?

thanks
Grant


--

w: http://jcooney.net
t: @josephcooney

RE: Propagate Database changes to application

[Paul Stovell]

This is what I was talking about (I think):

http://msdn.microsoft.com/en-us/library/ms172133.aspx

Personally I'd probably just poll unless my demand load suggested notifications 
would work better.

Paul

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Paul Stovell
Sent: Tuesday, 29 March 2011 11:45 PM
To: ozDotNet
Subject: RE: Propagate Database changes to application

Correct, though once upon a time I did have an experiment that worked with 
query notifications. From memory you attach some kind of SqlDependency object 
to your SqlCommand (not the type that works with triggers - it used the same 
code as clustered views from memory).

There is a trade off either way you go. With a notification system you can end 
up "drinking from a fire hose" if the events happen too frequently under load 
(e.g., an Orders table probably isn't good for notifications). Systems that 
rely on polling tend to scale better (for example: this little thing called the 
internet) but that's a generalization.

Out of curiosity, is this something that needs to happen at the database level? 
Should more than one process really be writing to the database at once? Could 
it be done using a messaging system above the database?

Paul

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Grant Molloy
Sent: Tuesday, 29 March 2011 9:32 PM
To: ozDotNet
Subject: Re: Propagate Database changes to application

Ok..
well it looks like bindable linq only propagates changes from what it's got in 
memory already, not from changes in the database..

On Tue, Mar 29, 2011 at 9:26 PM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Hi Joseph,

I wasn't really looking at any particular single client solution..

If Paul Stovell is listening, what did you use in Bindable Linq.. I am 
downloading now to have a look, but thought you may be able to put into words 
for larger audience..

thanks


On Tue, Mar 29, 2011 at 9:59 AM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:
Re: client type - I was more wondering is it a web app? Windows app? 
Silverlight? Windows intranet app could do udp broadcast of changes from the 
server or something like that.

Sent from my iPhone

On 29/03/2011, at 8:18 AM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Thanks everyone for feedback..

Joseph,
SQL Server, yes, version either 2008 or 2008 R2.. More than likely R2, but not 
nailed down yet.
Client type is a DAL DLL.. I want the DAL to know when the data changes, and 
the client will subscribe to DAL events, and then DAL can fire off event when 
data is changed, and App can decide what to do about it.  Kind of like a 
publisher / subscriber model implementation.

I'm not 100% sure I'm going about it the right way or have the events in the 
right place (ie in the DAL)..

On Tue, Mar 29, 2011 at 1:55 AM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:
What type of client is it? Do you control the means by which data is written to 
the table? Are clients deployed to the internet or intranet? What kind of 
database are we talking about here (I assume you mean SQL Server, since you 
mention SqlDependency) but which version?

Joseph

On Mon, Mar 28, 2011 at 8:33 AM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Hi list,

I'm looking to have an application automagically update it's view of the data 
when the data in the connected database table changes.
I've seen two main ways to do this so far.
1. Poll the database every n seconds
2. Use the System.Web.Caching.SqlDependancy object.

Does anyone else know of any other better or smarter way of doing this ?

thanks
Grant


--

w: http://jcooney.net
t: @josephcooney

RE: Propagate Database changes to application

[Paul Stovell]

Correct, though once upon a time I did have an experiment that worked with 
query notifications. From memory you attach some kind of SqlDependency object 
to your SqlCommand (not the type that works with triggers - it used the same 
code as clustered views from memory).

There is a trade off either way you go. With a notification system you can end 
up "drinking from a fire hose" if the events happen too frequently under load 
(e.g., an Orders table probably isn't good for notifications). Systems that 
rely on polling tend to scale better (for example: this little thing called the 
internet) but that's a generalization.

Out of curiosity, is this something that needs to happen at the database level? 
Should more than one process really be writing to the database at once? Could 
it be done using a messaging system above the database?

Paul

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Grant Molloy
Sent: Tuesday, 29 March 2011 9:32 PM
To: ozDotNet
Subject: Re: Propagate Database changes to application

Ok..
well it looks like bindable linq only propagates changes from what it's got in 
memory already, not from changes in the database..

On Tue, Mar 29, 2011 at 9:26 PM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Hi Joseph,

I wasn't really looking at any particular single client solution..

If Paul Stovell is listening, what did you use in Bindable Linq.. I am 
downloading now to have a look, but thought you may be able to put into words 
for larger audience..

thanks


On Tue, Mar 29, 2011 at 9:59 AM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:
Re: client type - I was more wondering is it a web app? Windows app? 
Silverlight? Windows intranet app could do udp broadcast of changes from the 
server or something like that.

Sent from my iPhone

On 29/03/2011, at 8:18 AM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Thanks everyone for feedback..

Joseph,
SQL Server, yes, version either 2008 or 2008 R2.. More than likely R2, but not 
nailed down yet.
Client type is a DAL DLL.. I want the DAL to know when the data changes, and 
the client will subscribe to DAL events, and then DAL can fire off event when 
data is changed, and App can decide what to do about it.  Kind of like a 
publisher / subscriber model implementation.

I'm not 100% sure I'm going about it the right way or have the events in the 
right place (ie in the DAL)..

On Tue, Mar 29, 2011 at 1:55 AM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:
What type of client is it? Do you control the means by which data is written to 
the table? Are clients deployed to the internet or intranet? What kind of 
database are we talking about here (I assume you mean SQL Server, since you 
mention SqlDependency) but which version?

Joseph

On Mon, Mar 28, 2011 at 8:33 AM, Grant Molloy 
mailto:graken...@gmail.com>> wrote:
Hi list,

I'm looking to have an application automagically update it's view of the data 
when the data in the connected database table changes.
I've seen two main ways to do this so far.
1. Poll the database every n seconds
2. Use the System.Web.Caching.SqlDependancy object.

Does anyone else know of any other better or smarter way of doing this ?

thanks
Grant


--

w: http://jcooney.net
t: @josephcooney

[OT] BYO Computer @ Suncorp

[Paul Stovell]

I think this is pretty exciting:

The BYO (bring your own) device program at one of Australia's largest insurers 
means staff will be able to break free from the shackles of their 
company-issued PCs and plug in their personal laptops, tablets and smartphones 
into the enterprise network.

"We can supply you with desktops here, but if people want to bring in their 
Macs or other devices, then that's their choice. People should use the device 
they feel the most productive in.

"It is part of Suncorp's fundamental strategy to attract, develop and retain 
top talent and to give them a great place to work, and try to inspire them to 
do great things." Mr Smith said Suncorp's goal was not to have infrastructure 
be a constraint to people's innovation and ingenuity.

From The Australian:

http://www.theaustralian.com.au/australian-it/suncorp-goes-byo-in-hardware-as-staff-are-encouraged-to-plug-in-their-devices/story-e6frgakx-1226029655986

RE: Forcing Dispose to be Called.

[Paul Stovell]

Hi David,

You could do a check in the finalizer of the class to see whether dispose 
wasn't called, and Trace a warning or call Debugger.Break() to force the 
developer to take a look.

Paul

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Rhys Jones
Sent: Monday, 24 January 2011 10:38 PM
To: ozDotNet
Subject: Forcing Dispose to be Called.


Hi all,

Background:

 I've got a service connection that is limited to 5 logins, (internal app 
written in another dept, Java Webservice not WCF compatible.),  I've 
implemented a library (C# 3.5) that calls this and a number of different 
services to provide a coherent data source for our Excel (2003) applications.
In my dispose, I clean everything up correctly, connections are closed, 
webservice is disposed etc.

Problem:

 I need to find a way to force the developpers in my team and in the other 
teams that use my library to call the Dispose method after each use of the 
library.

Is there a pattern or does anyone have an idea, how I can put a limit on how 
long the object can be used for?
I can think of some really kludgy ways using elapsed time and throwing an 
exception.



Examples:


Good : all calls are closed, webservice is disposed, sockets closed etc.

 // Spring.Net
 public IPricingService PricingService { private get; set; }

 public IEnumerable GetPrices(int ref, DateTime date)
 {
using (PricingService)
{
return PricingService.GetPrices(ref,date,PricingProviders.All);
}
}


Bad : object is not closed, open sockets and the login used for this call will 
block until the webservice timeout.

 // Spring.Net
 public IPricingService PricingService { private get; set; }

 public IEnumerable GetPrices(int ref, DateTime date)
 {
 return PricingService.GetPrices(ref,date,PricingProviders.All);
  }


thanks
Davy,


"Always code as if the guy who ends up maintaining your code will be a violent 
psychopath who knows where you live."
- Martin Golding

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Paul Stovell]

I wonder if that's a product of TFS architecture - generally most companies 
have one TFS server, with many team projects and project collections. There are 
licensing/admin costs associated with doing it differently.

With a DVCS you might find you end up with lots of smaller repositories - one 
for the VS core, individual repositories for different VS features, different 
repositories for branches, different repositories for System.Web.* vs. WPF vs. 
WCF, etc.


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Kean
Sent: Saturday, 6 November 2010 4:32 AM
To: ozDotNet
Subject: RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

How big are the databases that you are using? I'd imagine that there would be 
huge savings in using a DVCS for small self-contained repositories, however, 
there would be a given size where using one would no longer be an advantage. 
For example, I can't imagine a DVCS working at Microsoft; a full enlistment in 
one branch in DevDiv is around 300 GB (times that by 100s of branches) - having 
everyone pull that down and all the history along with it, would not be fun.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Mark Ryall
Sent: Friday, November 05, 2010 11:19 AM
To: ozDotNet
Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

I'm using svn again now after using git and hg for a few years (tfs was in 
there too - i don't want to talk about that).  I always liked svn and found it 
adequate but don't anymore.

There's nothing a DVCS provides that you can't live without - just as 64Kb of 
RAM was once perfectly adequate.

There are just a whole lot of things with DVCS that suddenly become easier or 
possible.  While you might not have considered these things earlier (because 
you couldn't), you really miss them when you can't.
They are insanely fast - especially git.  You will notice how fast they are 
every time you need to do a commit.  Insanely fast encourages more frequent 
commits.  The fact that after a clone, you end up with the entire history of a 
project locally (including every branch) in far less time than svn would take 
to check out a single code line (due to all the thousands of tiny control files 
it needs to create in every directory) is the winner for me.

Hosting is free or really cheap (bitbucket/github/launchpad).

For an open source project, fork/send pull request is a much lower barrier to 
entry for collaboration than checkout/email patch file.  If you accept a pull 
request, that person's commit becomes part of your codebase as them without you 
needing to provide direct commit access (as opposed to their changes being 
committed from a patch by you).

I prefer to avoid branching where possible but they make branching effortlessly 
easy.  Merging with git/hg is trivial and is properly tracked unlike with svn.  
Merging is always awful but git in particular seems to have some preternatural 
ability to help you get it right.

DVCS won't make you taller, more muscular or attractive though (i've tried - it 
really doesn't work) so use your best judgement.

On Wednesday, 3 November 2010 at 6:43 PM, silky wrote:
On Thu, Nov 4, 2010 at 12:37 PM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:
argumentative? silky? GTFO!

:)


Most of my experience with DVCS has been with
mercurial (hg) which I've used for about the last 2 years for my personal
stuff. Before that I used SVN. I think the difference (from my point of
view) is that hg works well in a super-set of configurations to TFS/SVN. If
you were a solo developer with TFS installed locally then hg probably
wouldn't be that much better (it certainly handles branching, merging and
backing up more cleanly than TFS/SVN). But most people don't work that  way
- the server is remote. If you want to look at the 'history' for a file or
do a diff it's a network operation. Checking out is a network operation (at
least for TFS it is...not sur e about SVN). In the case of TFS 2008 when the
server was off-line work ground to a halt. With hg sometimes there _is_ no
central server. I've had good experiences collaborating with other devs
using hg with no central server set up, just sending patches back and forth
for synchronization. You can set up your development processes such that
your DVCS is fairly centralized (like things would be with TFS/SVN) - devs
commit and push/pull often. Then you just get the perf wins of local disk
I/O vs. network I/O and better merging capabilities.

Yeah, this is what I thought. And I can't help but feel this is
totally overrated. I mean, I don't know a single person who would say
using SVN is slow. It's never slowed me down at all (perhaps I'm just
slow in general?). Checkout takes a while, sure, but you don't do that
every day. Infact, you normally only do it a few times, perhaps when
creating a branch or something.

O kay, so you are telling me that perhaps git/hg i

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Paul Stovell]

>> Broken how?

Let's say you decide to implement a new feature in a TFS branch. You branch the 
trunk to FeatureX. Over the course of a week, you make 13 check-ins to that 
branch. During this time, the rest of your team made another 19 changes to the 
trunk. The feature is now stable, so you decide to merge. In TFS, this is done 
by doing a giant compare on the two directories, AND'ing them together, and 
seeing what falls out. You aren't just merging a check-ins - you're merging the 
state of two file system directories after 32 different check ins in a single 
attempt - you better get it right, because if you get 90% of the way in and 
screw it up, it will take a long time to recover. 

When you're done merging, you're left with  a huge pending check in that 
touches every file involved in those 13 commits. You have to come up with a 
nice paragraph that sums up the 13 changes you're mushing in, because when you 
delete the branch, you'll probably lose the history of those branched changes. 
You should also remember to associate it with all of the work 
items/bugs/stories those 13 check ins touched, since this huge check in is 
really associated with all of them. 

In Mercurial it works different. You'd pull the 19 changes made to the trunk to 
your local repository - they'd be replayed, one-by-one, against your files. 
You'll still do the merges (leaving alone that Mercurial does a much better job 
of merging than TFS out of the box), but since you're dealing with one or two 
commits at a time, the merges are pretty simple, and if you screw up, you don't 
have to start the whole thing again. Once you've merged the trunk into your 
branch, you'd just push everything back to trunk. Now all the changes are 
replayed against trunk, and trunk has all 32 commits, with their history and 
dates exactly as you wrote them when you checked them in during the week. It's 
a much more elegant model. 

Paul

-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of silky
Sent: Thursday, 4 November 2010 4:51 PM
To: ozDotNet
Subject: Re: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

On Thu, Nov 4, 2010 at 5:40 PM, Paul Stovell  wrote:
> Hi Silky,
>
> I think in some ways you have to experience it - the proof is in the 
> tasting. But here are some things I like about it that work even for 
> small, local teams.
>
> 1.   How many times did you make a small change, then delete it 
> and try something else, only to realize that you didn't check in 
> during that time since it wasn't "ready" to share with the team? Since 
> most of your interaction with source control is just to your hard 
> disk, you're more likely to use it. On my current project with 
> Mercurial I'm averaging a commit every 10 minutes - lots of small changes.

Never. I don't ever try the wrong thing.

Seriously though, as I said to Joseph, I agree this is a legitimate benefit, 
and I like it.


> 2.   How many times have you done an SVN update/TFS "get latest", 
> tried to merge, made a mistake, and lost changes in the process? With 
> Mercurial that doesn't happen -it forces you to commit your local 
> changes first, then merge them with the server changes. If it fails, 
> you can roll it back and try again until you're successful - you never lose 
> changes.

This I've legitimately never done. Merging with SVN is pretty nice, at least I 
think so. You just go around resolving conflicts. Not so tough. Don't disagree 
that it could be better, but I don't think there is an issue here particularly.


> 3.   Merging in DVC's works fantastically. By comparison the 
> merging approaches of TFS and Subversion are broken. To even use a 
> DVCS you're using branching and merging, since the server and your 
> local machine are entirely different repositories. In TFS and SVN, 
> branching and merging is a scary concept only used in the most dire of 
> circumstances.

Broken how?


> Those advantages apply in the most connected corporate environment - 
> when I'm forced to use TFS I wish it had better support for these three 
> features.
> Prior to using Mercurial I just accepted that the way SVN made me work 
> was fine, and the occasional loss of code or busted merge was a fact of life.
> Now I find it frustrating to work with TFS/Subversion and sometimes 
> wonder if a folder full of "copy of .".zip files would be more 
> effective J
>
> There are other advantages to do specifically with open source 
> projects - for instance, instead of sending a patch, people can put 
> their repository online to share with others, and you can cherry pick 
> the changes you want from them. The patchi

RE: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?

[Paul Stovell]

Hi Silky,



I think in some ways you have to experience it - the proof is in the tasting. 
But here are some things I like about it that work even for small, local teams.



1.   How many times did you make a small change, then delete it and try 
something else, only to realize that you didn't check in during that time since 
it wasn't "ready" to share with the team? Since most of your interaction with 
source control is just to your hard disk, you're more likely to use it. On my 
current project with Mercurial I'm averaging a commit every 10 minutes - lots 
of small changes.

2.   How many times have you done an SVN update/TFS "get latest", tried to 
merge, made a mistake, and lost changes in the process? With Mercurial that 
doesn't happen -it forces you to commit your local changes first, then merge 
them with the server changes. If it fails, you can roll it back and try again 
until you're successful - you never lose changes.

3.   Merging in DVC's works fantastically. By comparison the merging 
approaches of TFS and Subversion are broken. To even use a DVCS you're using 
branching and merging, since the server and your local machine are entirely 
different repositories. In TFS and SVN, branching and merging is a scary 
concept only used in the most dire of circumstances.



Those advantages apply in the most connected corporate environment - when I'm 
forced to use TFS I wish it had better support for these three features. Prior 
to using Mercurial I just accepted that the way SVN made me work was fine, and 
the occasional loss of code or busted merge was a fact of life. Now I find it 
frustrating to work with TFS/Subversion and sometimes wonder if a folder full 
of "copy of ...".zip files would be more effective :)



There are other advantages to do specifically with open source projects - for 
instance, instead of sending a patch, people can put their repository online to 
share with others, and you can cherry pick the changes you want from them. The 
patching system really fails once a patch gets a little old.



Paul





-Original Message-
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of silky
Sent: Thursday, 4 November 2010 8:29 AM
To: ozDotNet
Subject: Why DVCS, was Re: TFS Feedaback? Anyone moved away from it?



On Thu, Nov 4, 2010 at 6:26 AM, Joseph Cooney 
mailto:joseph.coo...@gmail.com>> wrote:

> I've used TFS on and off since about 2006 (mostly because I was

> working at MS, as they are fond of TFS), but haven't used TFS 2010.

> It's biggest strength IMO is integration - requirements, work items,

> bugs, builds, source code and project documentation all from within

> Visual Studio. It's biggest weakness is that it's not a distributed

> version control system (git, mercurial).



Without sounding too argumentative; exactly why should I care that version 
control is "distributed"?



The stated arguments seem to be that you don't need to be online to do commits, 
or that there is a local history, or some other such things.

I really just don't ever find the need for anything like that; am I doing 
something significantly different to everyone else?



I mean, I've glanced over this:

http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

and it seems none of the benefits are really appropriate in a 'typical' 
environment.



I guess what I'm asking is - is anyone, working in an office or alone, getting 
specific benefits from git or whatever, that come *purely* from it being 
significantly different from SVN, and exactly what are they?





> If you're just going to use it as a revision control system you're

> missing out on 80-90% of what TFS has to offer (and thus it might not

> be worth it). TFS 2010 is a major update to the product (v2 really,

> since

> 2008 was really a v1.1) so I'm doubtless overlooking some cool

> features there 'cause I haven't used it.

> Joseph

>

> w: http://jcooney.net

> t: @josephcooney



--

silky



http://dnoondt.wordpress.com/



"Every morning when I wake up, I experience an exquisite joy - the joy of being 
this signature."

RE: MVVM in a navigational paradigm

[Paul Stovell]

Re: mapping views to view models, I like to use a convention to map view models 
to views (e.g., FooViewModel should expect a .xaml file named FooPage, FooView 
or FooWindow). So you shouldn't have to store the mapping explicitly.

In Magellan with just MVVM it goes something like this:


1.   You tell an INavigator that you want to navigate, specifying:

o   The name of the ViewModel ("foo")

o   Any parameters (customerID=36)

2.   The INavigator maps it to a handler

3.   The MVVM handler resolves the VM from the IOC container

4.   The MVVM handler looks for an Initialize() method on the view mode 
that takes the navigation parameters - e.g.,
public void Initialize(int customerId) {...}

5.   A view is found for the ViewModel based on the conventions above

6.   The view's DataContext is set to the ViewModel

The process is different if you're using MVC controllers, but not too 
different. The VM also implements an IViewAware interface and is notified about 
view lifetime events (e.g., activated, deactivating (closing) and deactivated). 
And each step uses interfaces and strategies to make it easy to plug in to, 
like ASP.NET MVC.

Paul


From: ozwpf-boun...@list.ozwpf.com [mailto:ozwpf-boun...@list.ozwpf.com] On 
Behalf Of Winston Pang
Sent: Wednesday, 3 November 2010 6:03 PM
To: ozDotNet; ozWPF
Subject: MVVM in a navigational paradigm

Hey guys,

I'm trying to apply MVVM in the WPF navigation model.

I was just doing some thoughts around it

Apart from the rule that the view model shouldn't know about the view, how 
would a particular view spawn another view, and push it to the navigation 
service for example? I've been playing around with some ideas of holding a 
mapping between the View and ViewModel in a global list in App. Then have App 
register against the messenger/mediator to respond to any other view model's 
wanting to spawn a new view and navigating it to it. I'm not sure if I'm on the 
right track.

Would love to see how some other people have done it on here?


Thanks.


--Winston

RE: MVVM in a navigational paradigm

[Paul Stovell]

In Magellan a ViewModel has access to an INavigator service, which it can use 
to navigate to other ViewModels or controllers. For example:

private void SaveCommandExecuted()
{
 Navigator.Navigate(c => c.Save(this));
}

The controller action might be:

public ActionResult Save(MyViewModel vm)
{
// Save data from vm
return Page("ThanksForSaving", new ThanksForSavingViewModel());
}

The latest Magellan release also has the ability to navigate between VM's 
without using controllers at all.

I guess it comes as no surprise that my response would be WPF + navigation = 
Magellan :) But if you're rolling your own you could look at that approach.

In more composite applications I use a pub/sub eventing system to navigate - it 
might be:

events.Publish(new NavigateEvent(vm => vm.Initialize(x,y), 
"Shell-TopLeftRegion"));

The navigation mechanism would subscribe to that event and figure out where to 
show the corresponding view.

Paul


From: ozwpf-boun...@list.ozwpf.com [mailto:ozwpf-boun...@list.ozwpf.com] On 
Behalf Of Winston Pang
Sent: Wednesday, 3 November 2010 6:03 PM
To: ozDotNet; ozWPF
Subject: MVVM in a navigational paradigm

Hey guys,

I'm trying to apply MVVM in the WPF navigation model.

I was just doing some thoughts around it

Apart from the rule that the view model shouldn't know about the view, how 
would a particular view spawn another view, and push it to the navigation 
service for example? I've been playing around with some ideas of holding a 
mapping between the View and ViewModel in a global list in App. Then have App 
register against the messenger/mediator to respond to any other view model's 
wanting to spawn a new view and navigating it to it. I'm not sure if I'm on the 
right track.

Would love to see how some other people have done it on here?


Thanks.


--Winston

Re: ASP.NET Web Forms vs MVC vs ...

[Paul Stovell]

I'd think a primary driver would be for the advantages of imperative code -
it's very easy to do this:

<% foreach (var customer in Model.Customers) { %>
   <%= customer.Name %>
<% } %>

And requires no changes to the ASPX compilation engine. Using tags, the
current ASPX renderer would try to treat them as controls, which would mean
using repeaters to iterate, which means binding, which potentially means
events and a more complete page lifecycle - not just simple page rendering
anymore.

That said, custom View Engines for ASP.NET MVC like Spark or NVelocity can
give you a tag-like rendering syntax:

   ${customer.Name}

http://sparkviewengine.com/

Paul


On Wed, Mar 24, 2010 at 2:37 PM,  wrote:

> Actually, I have a question that might extend this thread just a little bit
> more - why do we need to
> have yellow code in our mvc forms when Microsoft could have written user
> controls that generate
> the required code? Was it just so they could introduce Linq into the forms?
> Or did they just not get
> around to creating the tags?
>
> forget what the syntax of asp.net mvc is, but I think something along the
> lines of
> 
>   Customer Name: 
> 
> instead of the current yellow code equivalent?
>
>
>
>
> On Wed, Mar 24th, 2010 at 1:03 PM, Liam McLennan 
> wrote:
>
> > The original question implied that Umbraco are rewriting for the
> > purpose of
> > moving to MVC. I think it is much more likely that they were planning
> > to
> > rewrite for other reasons and decided to take the opportunity to
> > switch to
> > the superior platform. Rewriting a large app just to switch from
> > webforms to
> > mvc would be stupid in most cases.
> >
> > On Mon, Mar 22, 2010 at 5:42 PM, silky 
> > wrote:
> >
> > > On Mon, Mar 22, 2010 at 6:00 PM, Paul Glavich
> > >  wrote:
> > > > I am not arguing for or against webforms but the previous
> > argument around
> > > > battling with the likes of grid events doesn't really do the
> > argument
> > > > justice. I mean, if u don't like the grid events, use a repeaters
> > and
> > > push
> > > > whatever u want down the wire. You can still iterate over
> > collections in
> > > > webforms just like MVC and output whatever goo you like.
> > > >
> > > > It's interesting tho as the event model that you say you battle
> > so much
> > > with
> > > >
> > > > IS a compelling piece for many other devs. As always, horses for
> > courses.
> > > > I haven't seen anybody mention model binders yet which I find a
> > > compelling
> > > > yet conceptually simple piece of MVC.
> > >
> > > It's[1] only marginally different from using an object data source,
> > surely?
> > >
> > > This is what seems so useless about this entire thread.
> > >
> > > I think everyone has something different in mind when they compare
> > one
> > > thing and another.
> > >
> > > *shrug*, to quote Woody Allen (or Larry David, in character)
> > "whatever
> > > works". Doesn't make sense to be blindingly in love with one
> > > particular method or anything (exceptions are obvious [and
> > > hilarious]).
> > >
> > >
> > > > - Glav
> > >
> > > --
> > > silky
> > >
> > >  http://www.programmingbranch.com/
> > >
> > > [1] Reference:
> > http://msdn.microsoft.com/en-us/library/dd410405.aspx
> > >
> >
> >
> >
> > --
> > Liam McLennan.
> >
> > l...@eclipsewebsolutions.com.au
> > http://www.eclipsewebsolutions.com.au
> >
>
>
>
>


-- 
Paul Stovell

Re: SPAM-LOW: Re: ASP.NET Web Forms vs MVC vs ...

[Paul Stovell]

That's right Craig. I think Leon said it well:

Let people be people -- let them be vague and a little incorrect -- listen
more for the gist of what they're saying than the exact terminology.

http://secretgeek.net/program_communicate_4reasons.asp


On the flip side, I shouldn't have been so lazy as to shorten it. Sorry if
that confused anyone.

Paul



On Wed, Mar 24, 2010 at 11:00 AM, Craig van Nieuwkerk wrote:

> >> I agree with what you have said - web forms was revolutionary, and MVC
> >> learnt a lot because of the experiences the team had. I also think it
> would
> >> have worked the opposite way - had MVC been released first, it might
> have
> >> changed how/whether Web Forms was created. I also agree that Web Forms
> has
> >> many good qualities and makes a good choice in many situations.
> >
> > The MVC pattern is very old and most certainly was NOT informed in any
> way
> > by the design of ASP.NET web forms.
>
> Yes, but I am fairly confident when he was saying MVC he mean ASP.NET
> MVC. It's just shorter to write!
>



-- 
Paul Stovell

Re: SPAM-LOW: Re: ASP.NET Web Forms vs MVC vs ...

[Paul Stovell]

Hi Paul,

I agree with what you have said - web forms was revolutionary, and MVC
learnt a lot because of the experiences the team had. I also think it would
have worked the opposite way - had MVC been released first, it might have
changed how/whether Web Forms was created. I also agree that Web Forms has
many good qualities and makes a good choice in many situations.

I think there are two dimensions to this - the point of view of a developer
who has to choose between the two, and the point of view of Microsoft, who
have to maintain the two.

>From Microsoft's point of view, having both makes sense. Microsoft do a good
job of not picking favorites and instead just provide options. Want web to
feel like Win Forms programming? Here you go. Want it to feel like Rails?
Here you go. It makes for them to maintain both while there's an audience.
It's good that they are aware of the MVC learning curve and have a solution
for this.

>From the point of view of a developer confronted with a choice between the
two, I can see that there are cases when Web Forms would win out. However -
and this is just me - I think a lot of the reasons for choosing web forms
are short-term focussed:

   - The team are familiar with Web Forms
   - Introducing MVC would require training and we don't have time
   - The UI is very grid and data focussed, and we can drag and drop our way
   to our heart's content
   - We want to make use of in-house frameworks and code that build on Web
   Forms
   - We're capturing lots of data and viewstate would really be handy
   - There's a specific third-party control that we just can't live without

For me this means I'd be making a tactical decision for my project to go
with Web Forms - because of budget, time, etc. However, if I were to take a
long term view, and I didn't have any of those short-term constraints, then
ASP.NET MVC would generally be my default choice. In other words, I would*
 want* to use MVC, but I might *have* to use Web Forms.

I don't spend enough time in the web space, so the hardest part for me is
thinking of situations where Web Forms makes a good long term strategic
choice, rather than just a tactical solution to a short-term time/budget
constraint. I'd love to hear some examples of these situations if you have
any.

Paul



On Fri, Mar 19, 2010 at 4:59 PM, Paul Glavich wrote:

> Hey Paul & rest of list,
>
> Webforms was and is not bad. At it's conception it was revolutionary. If
> ASP. NET Mvc had come out first, it would have had less of a "known problem
> space" to learn from and prolly would not be as good as it is now. In fact,
> webforms will continue to play a huge part.
>  Microsoft is acutely aware of the current barrier in terms of learning
> curve to start developing on the MSFT stack. ASP.NET Mvc doesn't really
> help as it requires a good base understanding of frameworks and design
> principles. Webforms has a good leg up here with rich controls to use,
> purist and technical usage aside. However it still requires some framework
> knowledge.
>
> At any rate, I love both. Webforms can and does work well. So does Mvc.
> Both require more effort in different areas of the dev process.
>
>  A good example is the update panel. This control is brain dead easy to
> use, automatically caters for non js scenario but can transfer excessive
> amounts of data and get tricky in complex situations. Mvc has no such
> productivity boosting out of the box control. However u can do the same with
> more effort but also yield great flexibility in the control of what goes
> down the wire and interaction with ur page. So both can work with positives
> and negatives either way.
>
> If webforms was a lot more extensible, would ur argument change? The team
> is actively working towards this in future design considerations.
>
>
> - Paul
>
> Sent from my iPhone
>
> On 19/03/2010, at 4:27 PM, Paul Stovell  wrote:
>
> >> As a completely unrelated note, one of the original crew on WebForms
> sits down the hall from me - part of me wants to walk into his office, grab
> him by the collar and say 'What were you thinking?!!!'
>
> Although I personally came to dislike the Web Forms model, I do think it
> was innovative and an idea that deserved to be tried, and I'm sure the
> people who worked on it were very smart. Even bad ideas deserve a chance to
> see if they float - that's how we learn. I think the only mistake was
> waiting this long to absorb the thinking of other communities and to try
> something different.
>
> Paul
>
>
>
> On Fri, Mar 19, 2010 at 3:05 PM, David Kean < 
> david.k...@microsoft.com> wrote:
>
>>  By MVC here I'm clearly talking about <http://ASP.NET>ASP.NET MVC, not
>> the pa

Re: ASP.NET Web Forms vs MVC vs ...

[Paul Stovell]

Hi,

>> From quick read I did here :
http://msdn.microsoft.com/en-us/library/015103yb(VS.71).aspx I have no real
issue with it (it's not saying, for example, business logic goes in X area,
etc).

For me, it's not about the practices the framework dictates; it's more about
how the framework is designed.

ASP.NET has a pipeline - modules and handlers. Architecturally, a pipeline
makes a lot of sense for anything that is oriented around request and
immediate response.

However, ASP.NET Web Forms flattens the pipeline. Instead of going through a
series of objects to process a request, you go through some modules, and
suddenly end up at one big fat object - the Page. To extend it, you make use
of inheritance and the template method pattern.

Design pattern books and our own experiences teach that we should try to
extend through composition rather than inheritance.
Request processing pipelines should ideally be built through many objects
(chain of responsibility, pipes and filters architecture, etc.), rather than
through a series of method calls in one super object.

Some aspects of how Web Forms are built do follow this pattern of
composition. Control Adapters, for example, are a nice way of extending
without inheritance. Controls allow composition of a page which helps, but
they themselves follow a template method pattern and rely on inheritance.

WCF's major advantage is that it is oriented around a pipeline. Different
objects like dispatchers, message serializers, parameter validators,
instance context initializers, method invokers, and so on play a part in
that request processing pipeline. If you don't like any aspect of WFC, you
can plug your own components into that pipeline. There isn't a single object
you can point to that contains 80% of the functionality and you simply can't
use WFC without it (at least not that I've seen).

ASP.NET MVC is similar. Processing an MVC request involves many objects -
controller factories, controllers, action invokers, method descriptor, model
builders, action filters, result filters, action results, and view engines.
I can provide my own implementation of any of these while still getting the
advantage of the others. None of the objects are irreplaceable. In Web
Forms, I either use the Page object, or I'm not using Web Forms - there's no
way to substitute it.

In essence, it comes down to ASP.NET MVC using lots of small objects, while
ASP.NET Web Forms uses few very large objects. The large body of industry
knowledge in this area tells us the former is a better design. For me, this
translates to much more confidence in the framework to be able to handle my
needs without me hitting a dead-end or internal class and being told it
simply isn't possible to do what I want to do. Maybe that doesn't matter to
you, but when it comes to my personal preferences in choosing frameworks,
that's important to me.

Paul


On Fri, Mar 19, 2010 at 4:16 PM, silky  wrote:

> On Fri, Mar 19, 2010 at 4:27 PM, Paul Stovell wrote:
>
>> >> As a completely unrelated note, one of the original crew on WebForms
>> sits down the hall from me - part of me wants to walk into his office, grab
>> him by the collar and say 'What were you thinking?!!!'
>>
>> Although I personally came to dislike the Web Forms model, I do think it
>> was innovative and an idea that deserved to be tried, and I'm sure the
>> people who worked on it were very smart. Even bad ideas deserve a chance to
>> see if they float
>>
>
> Go on then; feel free to describe exactly all the issues with that you are
> calling the "web forms" model.
>
> From quick read I did here :
> http://msdn.microsoft.com/en-us/library/015103yb(VS.71).aspx I have no
> real issue with it (it's not saying, for example, business logic goes in X
> area, etc).
>
>
>
>> - that's how we learn. I think the only mistake was waiting this long to
>> absorb the thinking of other communities and to try something different.
>>
>> Paul
>>
>
> --
> silky
>
>  http://www.programmingbranch.com/
>



-- 
Paul Stovell

Re: ASP.NET Web Forms vs MVC vs ...

[Paul Stovell]

Dear Silky,

>> You know you can implement an MVC model without ASP.NET MVC, Right?
>> What the hell does it matter what Microsoft pushes? Why don't you just do
things the way *you* think is best?

I'm not sure how this became about what I know, what matters to me, or about
what I choose to do. However, I am pleased to know that you care so much
about me.

The original question asked that had ASP.NET MVC been created before
ASP.NETWeb Forms, whether people would be going crazy about Web Forms
at this
point.

My point was that ASP.NET MVC is what it is because the team made use of
certain design principles. Had they followed them from the start, they might
not have created ASP.NET Web Forms at all, because many of those principles
go fundamentally against what Web Forms is all about. It's an observation
about the journey that the ASP.NET team may have taken that might have made
the original question moot. It has nothing to do with me or my choices.

Paul





On Fri, Mar 19, 2010 at 4:12 PM, silky  wrote:

> On Fri, Mar 19, 2010 at 4:17 PM, Paul Stovell 
> wrote:
> > > Are you really trying to suggest that the "MVC" model was
> > > invented *after* web forms?
> >
> > No. Perhaps that should have read ASP.NET MVC, though I thought that
> could
> > be assumed from the context.
>
> In context, your statement makes no sense, so I was giving you a
> chance to make some. You know you can implement an MVC model without
> ASP.NET MVC, Right? Here is Microsoft even showing you how :
> http://msdn.microsoft.com/en-us/library/ms998540.aspx
>
>
> > Let me rephrase. If Microsoft had built and
> > shipped the ASP.NET MVC framework as the Official Microsoft Way of
> building
> > web applications, prior to building and shipping ASP.NET Web Forms, then
> the
> > latter may not have even happened or would have (hopefully) turned out
> very
> > differently.
>
> What the hell does it matter what Microsoft pushes? Why don't you just
> do things the way *you* think is best? You can write anything they've
> written. I don't understand this obsession.
>
> I shouldn't even be responding to these emails; it's all so
> mind-bendingly stupid.
>
>
> > Paul
>
> --
> silky
>
>  http://www.programmingbranch.com/
>



-- 
Paul Stovell

Re: ASP.NET Web Forms vs MVC vs ...

[Paul Stovell]

>> As a completely unrelated note, one of the original crew on WebForms sits
down the hall from me - part of me wants to walk into his office, grab him
by the collar and say 'What were you thinking?!!!'

Although I personally came to dislike the Web Forms model, I do think it was
innovative and an idea that deserved to be tried, and I'm sure the people
who worked on it were very smart. Even bad ideas deserve a chance to see if
they float - that's how we learn. I think the only mistake was waiting this
long to absorb the thinking of other communities and to try something
different.

Paul



On Fri, Mar 19, 2010 at 3:05 PM, David Kean wrote:

>  By MVC here I'm clearly talking about ASP.NET MVC, not the pattern.
>
> My point is that there is a huge barrier to entry to presentation patterns
> such as MVC, MVP and MVVM - that if Microsoft was to adopt these as the only
> way to develop Web and Client apps, we wouldn't be as successful. There is a
> huge market of developers (mainly web based) under what we call the 'breadth
> developer' that would be excluded by these advanced concepts. Hell if you'd
> told me just over 9 years ago (years before I joined Microsoft) that I
> needed to learn not only this new thing called .NET but also this pattern
> called MVC, I would have turned and run. I would have probably stayed with
> ASP (which what I was using at the time), before long moving to something
> like similar like PHP. While now I can look back at my naivety and realize
> now that there is a whole better way of developing software, I really think
> that developers need to come to that realization themselves, and not have it
> forced down their throat by someone else.
>
> (As a completely unrelated note, one of the original crew on WebForms sits
> down the hall from me - part of me wants to walk into his office, grab him
> by the collar and say 'What were you thinking?!!!')
>  --
>  *From:* ozdotnet-boun...@ozdotnet.com [ozdotnet-boun...@ozdotnet.com] on
> behalf of David Connors [da...@codify.com]
> *Sent:* Thursday, March 18, 2010 9:12 PM
>
> *To:* ozDotNet
> *Subject:* Re: ASP.NET Web Forms vs MVC vs ...
>
>   On 19 March 2010 13:44, David Kean  wrote:
>
>>  Truthfully, if MVC came before WebForms,
>>
>
>  It did by a significant margin - but just not on .NET. That kind of
> underscores the point that people are adopting it because it is new (at
> least in their minds) - or perhaps ready made on .NET.
>
>   people wouldn't have flocked to the .NET platform like they did. There
>> was a reason that WebForms was so successful - it mimic'd the existing drag
>> and drop paradigm that VB6 developers were used to.
>>
>
>  Or in otherwords, web forms was an exercise in marketing rather than good
> engineering.
>
>  --
> David Connors (da...@codify.com)
> Software Engineer
> Codify Pty Ltd - www.codify.com
> Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417
> 189 363
> V-Card: https://www.codify.com/cards/davidconnors
> Address Info: https://www.codify.com/contact
>
>


-- 
Paul Stovell

Re: ASP.NET Web Forms vs MVC vs ...

[Paul Stovell]

>> Are you really trying to suggest that the "MVC" model was
invented *after* web forms?

No. Perhaps that should have read ASP.NET MVC, though I thought that could
be assumed from the context. Let me rephrase. If Microsoft had built and
shipped the ASP.NET MVC framework as the Official Microsoft Way of building
web applications, prior to building and shipping ASP.NET Web Forms, then the
latter may not have even happened or would have (hopefully) turned out very
differently.

Paul



On Fri, Mar 19, 2010 at 2:45 PM, silky  wrote:

> On Fri, Mar 19, 2010 at 2:25 PM, Paul Stovell 
> wrote:
> > I think that if MVC had come out first,
>
> Are you really trying to suggest that the "MVC" model was invented
> *after* web forms?
>
> --
> silky
>
>  http://www.programmingbranch.com/
>



-- 
Paul Stovell

Re: ASP.NET Web Forms vs MVC vs ...

[Paul Stovell]

I think that if MVC had come out first, there either wouldn't have been Web
Forms, or it would have turned out very differently. For me the attraction
to MVC isn't that I like the MVC pattern or that I love dealing with HTTP,
or even that using new stuff makes me feel warm inside. It's that the code
in the implementation of MVC is so extensible and pluggable and well
designed, that I feel confident using it - there are no leaky abstractions,
and I can override just about anything I want.

If MVC had been around first I think the .NET community would have had more
of a patterns and architecture focus and less of a "wiz-bang draggy-droppy
tool" focus. If Web Forms had then been invented, it would look very
different.

Paul



On Fri, Mar 19, 2010 at 9:26 AM, Richard Carde  wrote:

> It's Friday...
>
> On 16 Mar 2010, at 22:24, Jonathan Parker 
> wrote:
>
> Keep a lookout for Umbraco 5 as well as this is going to be written in
> <http://ASP.NET>ASP.NET MVC.
>
>
> I see this a fair bit and wonder... "If ASP.NET MVC came out first, would
> people now be saying 'going to be [re-]written in ASP.NET Web Forms'"?
> *shudder*
>
> It's new... it must be better?
>
> I understand the benefits of MVC (or, more realistically, not using the
> abuse of HTML & HTTP that is WebForms) as I have a classic ASP background
> and good understanding of the protocols used on the Interwebs, but it just
> seems like people jump on the latest and greatest without understanding what
> that brings (good and bad). More XSS, etc. perhaps? Dunno.
>
> I know MVC has some helpers to properly encode output and that's great
> providing you know how/when/why one uses them. Same goes for outputting into
> strings used by JavaScript - watchout for the apostrophes and backslashes
> etc.
>
> Thank goodness ASP.NET traps 'dodgy' characters like < and > in
> user supplied data
>
> --
> Richard Carde
>



-- 
Paul Stovell