Fwd: [TDD] {ARTICLE] ASP.NET MVC Framework
Adam Dymitruk
---------- Forwarded message ----------
From: Cory Foy <user...@cornetdesign.com>
Date: Nov 16, 2007 1:37 PM
Subject: [TDD] {ARTICLE] ASP.NET MVC Framework
To: testdriven...@yahoogroups.com
Scott Guthrie just posted the first overview of the ASP.NET MVC
Framework Microsoft is going to be shipping with VS2008:
http://weblogs.asp.net/scottgu/archive/2007/11/13/asp-net-mvc-framework-part-1.aspx
Looks amazingly like Rails... ;)
--
Cory Foy
http://www.cornetdesign.com
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch format to Traditional
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
m.sean.kelly
what I see.
Here's some of the goodness, IMHO:
1. Using custom attributes to signify that a method on a controller is
an "action" is an improvement over the Rails implementation wherein
any public method on the controller can be executed from a browser
with the proper URL.
2. The ability to map the URL parameters to action method parameters
beats using Rails' params dictionary.
3. Built-in support for NUnit and MBUnit, as well as MSTest.
4. The framework allows you to use any ORM option (including
NHibernate, LLBLGen, WilsonORMapper, MS Entities).
5. Ah...the Intellisense. The IDE vendors have really struggled with
bringing true Intellisense to Rails developers (Although CodeGear's
3rd Rail has made good strides in this direction).
6. Call me a control freak, but I prefer the MS MVC's approach of
explicitly passing data to the view instead of having all instance
variables on the controller be available to the view (as it is in
Rails). I prefer to have my intent be the result of explicit action,
rather than side-effect.
7. Oh...my...God. Support for both Rails style views with inline code
and HTML helper methods,
and views utilizing ASP.NET server-side controls. Cool! Without
postbacks and viewstate and the event lifecycle, the current suite of
third-party controls will
provide limited value but at least there's a path for the migration
of these controls to the new world. Although it's not clear yet that
they will (see
http://www.telerik.com/community/forums/thread/b311D-bamaht.aspx). I
can only imagine that
the control vendors are already stretched pretty thin supporting
classic ASP.NET and Silverlight.
But then, perhaps this just opens the door for things like YUI.
The openness of the framework (i.e. use any test framework you like
and use any ORM framework you like)
does, however, mean that MS MVC will not be able to provide as much
help out of the box as Rails does.
I can live without many of these nicities. For instance, none of these
are a deal breaker:
* Rails IDEs frequently know how to quickly navigate to the unit tests
for a model entity because of the
file and directory naming conventions. Simply hit a key combination
and you're switching between the
two files.
* Since Rails assumes specific test and ORM frameworks, it is able to
provide support for static
test data (i.e. "fixtures" in YAML files). Run the tests and the
database is auto-magically pre-populated
with this data.
* When you generate new controller and model classes, Rails also
generates test stubs.
The one Rails feature I'm most concerned about is the plugin support.
The Rails plugin architecture
pretty much assumes that the Rails application uses the Rails
ActiveRecord for ORM. A Rails plugin
frequently includes views, controllers, and models. There has been a
pretty active group of plugin
contributors in the Rails community (see http://agilewebdevelopment.com/plugins).
One might argue
that the plugin architecture is a core part of Rails' success. It will
be a challenge to develop plugins
where the ORM framework is unknown.
-=michael=-
Learning.com
Development Lead, Applications Group
On Nov 16, 8:21 pm, "Adam Dymitruk" <a...@dymitruk.com> wrote:
> Here it is: MS MVC.
>
> ---------- Forwarded message ----------
> From: Cory Foy <usergr...@cornetdesign.com>
> Date: Nov 16, 2007 1:37 PM
> Subject: [TDD] {ARTICLE] ASP.NET MVC Framework
> To: testdrivendevelopm...@yahoogroups.com
>
> Scott Guthrie just posted the first overview of the ASP.NET MVC
> Framework Microsoft is going to be shipping with VS2008:
>
> Looks amazingly like Rails... ;)
>
> --
> __._,_.___ Messages in this topic
> 1) Reply (via web post)
> <http://groups.yahoo.com/group/testdrivendevelopment/post;_ylc=X3oDMTJ...>|
> Start
> a new topic
> <http://groups.yahoo.com/group/testdrivendevelopment/post;_ylc=X3oDMTJ...>
> Messages<http://groups.yahoo.com/group/testdrivendevelopment/messages;_ylc=X3o...>|
> Files<http://groups.yahoo.com/group/testdrivendevelopment/files;_ylc=X3oDMT...>|
> Photos<http://groups.yahoo.com/group/testdrivendevelopment/photos;_ylc=X3oDM...>|
> Links<http://groups.yahoo.com/group/testdrivendevelopment/links;_ylc=X3oDMT...>|
> Database<http://groups.yahoo.com/group/testdrivendevelopment/database;_ylc=X3o...>|
> Polls<http://groups.yahoo.com/group/testdrivendevelopment/polls;_ylc=X3oDMT...>|
> Members<http://groups.yahoo.com/group/testdrivendevelopment/members;_ylc=X3oD...>|
> Calendar<http://groups.yahoo.com/group/testdrivendevelopment/calendar;_ylc=X3o...>
> [image: Yahoo!
> Groups]<http://groups.yahoo.com/;_ylc=X3oDMTJkYmlmOG5yBF9TAzk3MzU5NzE0BGdycEl...>
> Change settings via the
> Web<http://groups.yahoo.com/group/testdrivendevelopment/join;_ylc=X3oDMTJ...>(Yahoo!
> Change settings via email: Switch delivery to Daily
> Switch
> format to Traditional<testdrivendevelopment-traditio...@yahoogroups.com?subject=Change+Delivery+Format:+Traditional>
> Visit Your Group
> <http://groups.yahoo.com/group/testdrivendevelopment;_ylc=X3oDMTJkMW52...>|
> Yahoo!
> Groups Terms of Use <http://docs.yahoo.com/info/terms/> | Unsubscribe
> <testdrivendevelopment-unsubscr...@yahoogroups.com?subject=>
> Recent Activity
>
> - 23
> New Members<http://groups.yahoo.com/group/testdrivendevelopment/members;_ylc=X3oD...>
>
> Visit Your Group
> <http://groups.yahoo.com/group/testdrivendevelopment;_ylc=X3oDMTJlMGY0...>
> Y! Messenger
>
> All together now<http://us.ard.yahoo.com/SIG=12j5c3jkk/M=493064.10729668.11333359.8674...>
> Host a free online
>
> conference on IM.
> Ads on Yahoo!
>
> Reach customers
>
> searching for you.
> Curves on Yahoo!
>
> Curves, fitness
>
> and weight loss.
> .
>
Scott Bellware
On Nov 25, 2007, at 10:17 AM, m.sean.kelly wrote:
> a method on a controller is an "action" is an improvement over
> the Rails implementation wherein any public method on the
> controller can be executed from a browser with the proper URL.
Why is that an improvement? Rails relies quite a bit on convention
over configuration. Why add yet more line noise in the form of .NET
attributes to figure out something that has already been stated: a
public method on a controller can be executed publicly.
> The ability to map the URL parameters to action method parameters
> beats using Rails' params dictionary.
Looks good in the demos. You might still use the params collection
when you've got too many parameter arguments than would should be
sensible for a method signature.
> I prefer the MS MVC's approach of explicitly passing
> data to the view instead of having all instance variables
> on the controller be available to the view (as it is in
> Rails). I prefer to have my intent be the result of explicit
> action, rather than side-effect.
What's not explicit about setting an instance variable? The only
instance variables set on a Rails controller are data sent to the
view. The semantics of a controller in Rails suggests that this is
the explicit mechanism for passing data.
Ayende Rahien
On Nov 25, 2007, at 10:17 AM, m.sean.kelly wrote:
> a method on a controller is an "action" is an improvement over
> the Rails implementation wherein any public method on the
> controller can be executed from a browser with the proper URL.
Why is that an improvement? Rails relies quite a bit on convention
over configuration. Why add yet more line noise in the form of .NET
attributes to figure out something that has already been stated: a
public method on a controller can be executed publicly.
This can be seen as a improvement because of the security concerns.
I don't like it, but this is a valid argument.
> The ability to map the URL parameters to action method parameters
> beats using Rails' params dictionary.
Looks good in the demos. You might still use the params collection
when you've got too many parameter arguments than would should be
sensible for a method signature.
Or, you can use [DataBind] and have a method parameter.
Scott Bellware
On Nov 25, 2007, at 11:06 AM, Ayende Rahien wrote:
> This can be seen as a improvement because of the security
> concerns. I don't like it, but this is a valid argument.
I'm not clear on the issue. How does the vulnerability relate to
public methods vs. methods with attributes?
> Or, you can use [DataBind] and have a method parameter.
I'm not familiar enough with ASP MVC. What do you mean by 'method
parameter'?
Ayende Rahien
On Nov 25, 2007, at 11:06 AM, Ayende Rahien wrote:
> This can be seen as a improvement because of the security
> concerns. I don't like it, but this is a valid argument.
I'm not clear on the issue. How does the vulnerability relate to
public methods vs. methods with attributes?
The reasoning behind this decision, if I follow it correctly, is that developers may do something like:
public void SaveAndValidate(...)
{
if(valid)
Save();
}
// should not be an action
public void Save( ... )
{
}
Then, a nasty user can do something like:
/customer/save.mvc
And they will bypass validation.
Personally, I think that this is going back to consenting adults and trusting the developers (which, by the way, include whacking the developer as well, if they screw up). I don't like this [Action] attribute, but that is the reason for it.
It is fairly typical MS mindset, trying to make sure that you meant what you wanted.
> Or, you can use [DataBind] and have a method parameter.
I'm not familiar enough with ASP MVC. What do you mean by 'method
parameter'?
Refactoring, from method with a lot of parameters to a method parameter object.
public void NewUser(string username, string email, string password, string confirmPassword)
vs.
public void NewUser([DataBind] User user)
Scott Bellware
On Nov 25, 2007, at 4:00 PM, Ayende Rahien wrote:
> It is fairly typical MS mindset, trying to make sure
> that you meant what you wanted.
Yeah, that sucks. Too bad though. They could have shipped the tools
with a practice guidance effort that would see to it that doing stupid
things with controllers would be a matter of choice rather than
ignorance.
> public void NewUser([DataBind] User user)
I didn't realize that was possible in ASP MVC.
Since switching from MonoRail, I've become partial to the Rails way
using the params collection:
def new
user = params[:user]
end
The underlying mechanisms are quite different though.
Ayende Rahien
> public void NewUser([DataBind] User user)
I didn't realize that was possible in ASP MVC.
Since switching from MonoRail, I've become partial to the Rails way
using the params collection:
def new
user = params[:user]
end
The underlying mechanisms are quite different though.
It isn't. At least, not right now. Hammett implemented support for that and for IParameterBinder, but I have no idea if this is going to be OOTB, probably not.
What is user in this case? A string?
Scott Bellware
On Nov 25, 2007, at 8:26 PM, Ayende Rahien wrote:
> What is user in this case? A string?
It's a Ruby Hash: http://www.ruby-doc.org/core/classes/Hash.html
A hash behaves like a dictionary. A Rails model object (ActiveRecord)
can be initialized by passing a hash to its constructor.
There are no real concrete fields on a model object. There are
dynamic accessors that look into the dictionary for the key/value that
corresponds with the accessor.
Internally, the value for user.name is stored in attributes[:name],
user.password is stored in attributes[:password].
Hash is like the universal mechanism in Rails and Ruby. Anytime you
see something like :name => 'Bob' it's a Hash. You don't need to do
much more to create one than something like my_hash = { :name =>
'Bob' }, or my_hash = :name => 'Bob', although you don't often see
that kind of thing except in test code (or framework code).
It's more likely that you'll see user = User.new :name =>
'Bob', :password => 'foo'.
And in the case of passing model data from the view to a controller
action:
def create
user = User.new params[:user]
...
end
m.sean.kelly
choice a bit. I see it as providing me the capability to express in
the code precisely what I mean--no more, no less. It's conceivable
that I may want to have a public method on a controller that I don't
want to be accessible from a browser. To be fair, I don't expect this
to be the common case, so perhaps it would be more convenient to have
a [NonAction] custom attribute that I apply in these special cases,
but I still want some way to distinguish public methods that are
available as actions and those that are not.
-=michael=-
On Nov 25, 2:00 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
m.sean.kelly
the action method explicitly state via method parameters, "This is
what I expect to be passed to this method." For me, this is part of
producing readable code. In a statically typed language, it also saves
me the trouble of doing the cast. But if I'm not mistaken, this is
simply an option which the developer may choose to use or not use. As
an option, gotta say I like having it. If it were enforced, I'd be
against it.
Ayende, you're probably already aware of this, but in Ruby :name
and :password are "symbols". Symbols are preceded by ":". A symbol is
a like a singleton for a string. Each use of the symbol points to the
same string in memory. In Ruby, you auto-magically get a symbol for
each method name and attribute name. This gets leveraged to a nice
effect in Rails. Martin Fowler has argued that symbols in Rails
constitute a kind of domain specific language for the application.
-=michael=-
Scott Bellware
On Nov 26, 2007, at 11:47 AM, m.sean.kelly wrote:
> It's conceivable that I may want to have a public method
> on a controller that I don't want to be accessible from a browser.
A controller class with a public instance method that isn't an action
is a design smell.
Putting attributes on actions is like putting a band aid on a design
problem rather than curing it.
Scott Bellware
On Nov 26, 2007, at 12:08 PM, m.sean.kelly wrote:
> I can see developer preferences on either side. Myself, I like having
> the action method explicitly state via method parameters, "This is
> what I expect to be passed to this method."
As long as your perspective of action invocation equates to method
invocation...
Even though a method, function, whatever is the construct that handles
the request, you could make a case for using a params collection as
more closely representing and signifying HTTP. At least, that's part
of my appreciation of the way that Rails influences the semantics of a
controller action.
Strongly-typed args in MonoRail are cool, but it can get unwieldy for
forms with a good number of fields. A method signature with 10+
arguments is a design smell for me. The args could be replaced with a
DTO, but a parameters collection on the request is already a DTO.
I'm not sure I'd create a strongly-typed parameter object just to
replace a hashmap.
Anyone know if ASP MVC exposes the equivalent of a Rails' params array?
m.sean.kelly
controller that isn't an action, while a logical possibility, has
little utility. Even in Ayende's example, the Save method really ought
to be protected and not public.
-=michael=-
m.sean.kelly
object from within an action.
-=michael=-
Ayende Rahien
I don't think that this has to do with DSL, though. Not the technical use, at least.
It is simply that this:
:foo => :bar
reads much better than
"foo" => "bar"
Scott Bellware
On Nov 26, 2007, at 7:07 PM, Ayende Rahien wrote:
> It is simply that this:
> :foo => :bar
> reads much better than
> "foo" => "bar"
Well that, and symbols are singletons.
This hash: "foo" => "bar, "foo" => "yo"
allocates memory for both instances of the "foo" string.
This hash: :foo => "bar", :foo => "yo"
allocates :foo once. And any subsequent uses of :foo will refer to
the same :foo space in memory.
Symbols are truly treated by the compiler as something other than a
string. They're part of the symbolic language of a model or API.
Symbols are something like a field definition on a .NET class - the
field is defined once on that class, no matter how many instance of
that class exist, and no matter what different data is held by that
field in each individual instance of the class. The definition of the
field is a single definition.
It's not a perfect analogy, but .NET doesn't have an ideal
representation of a symbol.
A symbol is a representational unit that doesn't have to belong to the
definition of any class or module. In can just live in the Ruby
object space, representing different things in different contexts.
Linguistically, they're something along the lines of a morpheme.
Because symbols are often thought of as linguistic units in Ruby
rather than strings, they play into the mindset of language-oriented
programming, and thus are in play in the Ruby DSL mindset.
Ayende Rahien
On Nov 26, 2007, at 7:07 PM, Ayende Rahien wrote:
> It is simply that this:
> :foo => :bar
> reads much better than
> "foo" => "bar"
Well that, and symbols are singletons.
This hash: "foo" => "bar, "foo" => "yo"
allocates memory for both instances of the "foo" string.
This hash: :foo => "bar", :foo => "yo"
allocates :foo once. And any subsequent uses of :foo will refer to
the same :foo space in memory.
Implementation detail.
Symbols are truly treated by the compiler as something other than a
string. They're part of the symbolic language of a model or API.
I don't see it that way, it is just a nicer syntax for this.
In .NET, :foo would be string.Intern("foo").
Symbols are something like a field definition on a .NET class - the
field is defined once on that class,
No, the proper correlation would be an interned string.
Scott Bellware
m.sean.kelly
> Linguistically, they're something along the lines of a morpheme.
> Because symbols are often thought of as linguistic units in Ruby
> rather than strings, they play into the mindset of language-oriented
> programming, and thus are in play in the Ruby DSL mindset.
magically get symbols for all attributes and method names. This
enables you to do things like the following:
class Person < ActiveRecord::Base
validates_presence_of :first_name
validate_on_create :validate_creation
...
end
Where :first_name is an auto-generated attribute that maps to a column
in the Persons table, and :validate_creation is a method defined in
the Person class.
-=michael=-
Jay R. Wren
I find value in being explicit.
http://martinfowler.com/ieeeSoftware/explicit.pdf
http://codebetter.com/blogs/jeremy.miller/archive/2005/08/24/131096.aspx
I MUCH prefer the approach in letting my class definition attributes
and/or HBM be the authority for the domain rather than the database
itself. I love that I can just ask NHibernate to generate the database
schema for me. I can now run my unit tests in sqlite, but my
dev/qa/production on PostgreSQL. I can change databases with very
little work.
Frankly, I'd love to see this extended with a declarative approach for
suggesting indexes and allowing CreateSchema or CreateIndexes.
I can't complain too much about the Rail's ActiveRecord approach. But
I don't like it. I'd much rather be able to look at my class
definition and know what is available than have to inspect a database.
--
Jay
Scott Bellware
On Nov 27, 2007, at 2:00 PM, Jay R. Wren wrote:
> I can't complain too much about the Rail's ActiveRecord approach. But
> I don't like it. I'd much rather be able to look at my class
> definition and know what is available than have to inspect a
database.
In Rails, you don't have to look at the database to know what's
available, you look at the migrations. Or, you can look at the
schema.rb that is generated when migrations are executed.
Michael Kelly
alteration scripts that can be run against a variety of database
management systems (MySql, Postgresql, MS SQL Server, etc). But I
wonder if Jay isn't also making the point that he'd prefer to work at
the level of the ActiveRecord (or "entity") class, and let the the
database take care of itself. The Castle Project's ActiveRecord
implementation (built on top of NHibernate) goes a long way in that
direction. Perhaps there's an opportunity to embrace and extend the
features of Rails' success (which is a nice segue into this
discussion: http://groups.google.com/group/altnet/browse_thread/thread/dcb4ee2a3e8e0f55?hl=en#d6c479db656956de).
-=michael=-
Ayende Rahien
Scott Bellware
On Nov 28, 2007, at 9:13 AM, Michael Kelly wrote:
> But I wonder if Jay isn't also making the point that he'd prefer
> to work at the level of the ActiveRecord (or "entity") class, and
> let the the database take care of itself.
I don't see the distinction being made.
I use ActiveRecord in Rails, and I work at the level of the entity -
or "model" in Rails parlance.
I guess I don't understand what is meant by "let the database take
care of itself."
Are you talking about a need for more sophisticated object to
relational mapping over and above what the ActiveRecord pattern
typically addresses?
Adam Dymitruk
Let me know more about it or if you put it on an SVN server somewhere.
Adam
Ayende Rahien
Adam Dymitruk
Jay R. Wren
I come back to a project having not worked on it for a time. With my poor memory, this can be as short as a couple of weeks. I don't recall which columns exist on tables. My ActiveRecord class definitions are as simple as
class UserOptions < ActiveRecord:Base
end
I can't remember which columns are on the UserOptions table, so I have to go browse using a DB tool to find out.
I prefer the explicit definition which Castle's ActiveRecord gives me. I can press F12 anywhere in visual studio to go definition. So find where UserOptions is used in my project, press F12 with the cursor over it, and I immediately know which properties are available.
I'm not touting the technical superiority of one vs the other. I don't think there is one. I'm simply stating that not every one likes to work the Ruby ActiveRecord way, and that there is nothing wrong with alternatives. There is possibly place for both, I simply prefer the later.
--
Jay