Should the Castle Project transform MonoRail into an implementation of MS MVC?
Michael Kelly
http://blog.eleutian.com/2007/10/16/MonoRailVsSystemWebMVC.aspx.
"What I'd like to see is MonoRail become more like Rails. I want to
see something built on top of MS MVC that even more-so favors
Convention over Configuration--including but not limited to generators
and such. I want it to take it to the next level and be exactly what
the community wants for a C# web platform. Dave Laribee says that
"MonoRail will remain a viable option for smaller or more edgy shops."
I think that's true, but I want to see it built on top of MS MVC."
MS MVC is ORM and unit test framework agnostic. This means that it is
not, and cannot, be the kind of opinionated framework that Rails has
become. Rails takes a stance on things. It says, "Hey, we're building
web applications and this is the way we think web applications ought
to be built". While it's possible to get creative and find ways to
express your own opinions while using Rails, the consensus seems to be
that one ought to just drink the kool-aid and get on with providing
value to customers. If you do so, then you get a lot of help from
Rails. By assuming certain conventions about the naming of things,
directory structures, and the like--*and* by assuming the use of
specific ORM and unit test frameworks--Rails can generate skeleton
code for both the application and the unit tests.
OK. Neat trick. But the value of Convention over Configuration goes
further. First, once the developer has imbibed the conventions she's
able to generate value for the the customer at a more rapid rate
because there are simply fewer technical (non-value-add) decisions to
be made. Deciding takes time. Second, it reduces the effort required
to make a developer productive on a new project (as long as they are
familiar with the conventions). Finally, and perhaps this is the
biggie, it makes possible pluggable slices of functionality that
include views, controllers, and models.
Check this: http://agilewebdevelopment.com/plugins. There is a rich
set of plugins now available to Rails developers for authentication,
authorization, rating, tagging, handling image upload and processing
for avatars, and the list goes on. These plugins would be quite
troublesome to create if you couldn't assume a specific ORM framework,
and they become much easier to transform if necessary (or contribute
to) because they adhere to the Conventions. The Rails plugin
architecture has been so successful that I'd argue that it is one of
the core features in the story of Rails' success, and that any Rails
imitators must imitate this as well to succeed.
So, here's my question (and my apologies for the long-winded way of
getting here): Should there be an open source framework built on top
of MS MVC that delivers the full value of Convention over
Configuration, and should that framework be a transformed MonoRail?
-=michael=-
Michael Kelly
Team Lead, Applications Group
Learning.com
Stuart Laughlin
>
> So, here's my question (and my apologies for the long-winded way of
> getting here): Should there be an open source framework built on top
> of MS MVC that delivers the full value of Convention over
> Configuration, and should that framework be a transformed MonoRail?
>
I don't know. :)
But don't IronRuby and Ruby.Net play a big part in this conversation?
When my customers ask me to create for them a website, an overwhelming
majority of them demand something that runs on Windows/IIS (I work for
a consulting company that specializes in Microsoft .Net technologies).
Assuming I want to take an MVC approach and eschew WebForms (and I
have taste, so I do ;) ), today I really have only one choice, and
that's MonoRail [1]. Soon, though, MS MVC will obviously be an option,
and at some point (with the advent of a production-ready IronRuby or
Ruby.Net) I assume an outright Ruby on Rails app will be an option.
So, while today I have only one MVC framework at my disposal
(MonoRail), in six months (let's say) I'll have three (MonoRail, MS
MVC, RoR). The question in my mind, then, is how will these
technologies differentiate themselves? What will be the pros/cons of
each? What value will each provide? For example, MS MVC will deliver
most of the value of MonoRail *plus* a Microsoft logo! But I
digress...
Relating this back to the OP's question...
> Should there be an open source framework built on top
> of MS MVC that delivers the full value of Convention over
> Configuration, and should that framework be a transformed MonoRail?
I can see a certain amount of value in that proposition. Do you want
an ultra-configurable MVC framework that allows the use of any of the
.Net languages? Use MS MVC. Do you want to be able to use any of the
.Net languages yet you value "convention of configuration", i.e. are
you satisfied that a certain number of sensible constraints will
enable rather than hinder your productivity for this particular
project? Use MS MVC + MonoRail. Do you want to write your app using
ruby in emacs on a debian box? Use Ruby on Rails and deploy it on
IIS/ASP.Net (don't mind if I do!).
Bottom line, there is differentiation in what is being proposed,
whereas the way things are going today MS MVC seems to be nothing more
than a reinvented, Microsoft-branded MonoRail. What's being proposed
basically gives up the fight to make MonoRail a better platform than
MS MVC. It vacates the "configurable ASP.Net MVC framework" arena,
let's MS MVC become the de facto standard, and via this new "MonoRail"
adds value (constraints and extension points) on top of it.
1: I'm sure there must be some other MVC frameworks for ASP.Net, but I
haven't seen any as used/mature as MonoRail.
--Stuart
Scott Bellware
> built on top of MS MVC that delivers the full Convention
> over Configuration
I wouldn't say that ASP MVC is based on Convention over Configuration
at all. There's a mess of avoidance of convention in the default
implementation - relative to Rails that is.
Attributes for controller actions and the need to explicitly render
views are two configuration over convention issues that come to mind
immediately - and those are just the ones I remember, and only from
having watched a demo of the framework.
I'm not going to be surprised to find yet more configuration over
convention stuff in ASP MVC. In fact, I expect to see an open source
project that brings convention over configuration to ASP MVC
immediately, rather than having to wait for Microsoft's ivory tower
theories to catch up to lessons already learned in practice in the
field.
Michael Kelly
On Nov 28, 10:31 am, Scott Bellware <sbellw...@yahoo.com> wrote:
>
> > built on top of MS MVC that delivers the full Convention
> > over Configuration
>
> I wouldn't say that ASP MVC is based on Convention over Configuration
> at all. There's a mess of avoidance of convention in the default
> implementation - relative to Rails that is.
community needs to pay attention to the early information about MS MVC
and let their opinions be known.
-=michael=-
Scott Bellware
On Nov 28, 2007, at 1:21 PM, Michael Kelly wrote:
> There may yet be an opportunity to influence this. But the developer
> community needs to pay attention to the early information about MS
MVC
> and let their opinions be known.
Done. Feedback was given, and dismissed. In fact, the first instance
of feedback on this is on tape from the presentation at the ALT.NET
conference. The follow-up conversation is not recorded, but was just
more of the same.
This is yet another triumph of theory over practice. It's the way
that Microsoft folks - even the best of `em like Scot Guthrie - have
become used to doing product design. As always, in two years they'll
light on what we were talking about back then, but it will of course
be too late.
The stock "you can write your own policy plug-ins for Convention over
Configuration" is an intellectually bankrupt position... There's no
reason that the frameworks I use shouldn't come out of the box ready
to go. I'm too busy to be fixing frameworks while also also building
product for my customer.
Anyway... same old same old insular Redmond.
Scott Hanselman
position" don't move the wants and needs of the larger community
forward, and I'd say that was a very *party pooper* position on your
part, ScottB. With all due respect, I wonder sometimes if you want
projects like ASP.NET MVC to fail so you can point a prescient knowing
finger at the result.
Phil is the PM for the project, and there is a VERY small team of
devs. Have you emailed or called Phil? I'm sure he'd be happy to do a
conference call. I just don't think that's "same old insular Redmond."
In 15 years of working outside of Microsoft I haven't found them as
insular as you insist they are. They don't always agree, but in my
experience they do listen. Call me Borg or call me the Matrix, but
don't call me insular.
I am listening and I personally think that Aaron's idea of Monorail
becoming the Convention to MVC's Configuration is a great idea and
should be explored.
Phil Haack
I didn't realize that there was an ALTNET Mailing list along with the
ALTNETCONF mailing list. ;)
Whether or not Castle should "lay the tracks" on top of ASP.NET MVC is
obviously a decision for the Castle team. I personally don't know if
they've decided if they will compete with ASP.NET MVC head on or look
to carve out an ecosystem on top of it. In talking to Hammet though,
he was somewhat favorable to what we've done so far and provided a lot
of valuable feedback. As he pointed out (http://
hammett.castleproject.org/?p=219), it really depends on how well
executed the final MVC project looks before they decide whether or not
to continue work with MonoRail.
Another open source project that currently has the goal to be the
"sugar" on top of ASP.NET MVC is Subsonic. As you probably have heard,
Rob Conery was hired by Microsoft to continue work on Subsonic as an
independent OSS project (please don't roll your eyes, it's true!). ;)
My personal gut feeling is that these two projects probably have
different philosophies on how to attack a framework. I don't think one
is necessarily superior to the other in all ways. After all, there is
no such thing as a "perfect design". Only designs that are optimized
for one set of constraints over another set of constraints. I think
those who are drawn to one philosophy over another will enjoy having
the choice.
Phil
Scott Bellware
my job to make it succeed. If it's good, it should should succeed. If
it's not good, it should fail. If it's mediocre, it should simply
loiter and be surrounded with exaggerated assurances and platitudes
from evangelists-for-hire.
I haven't emailed Phil. My experience with Microsoft as reinforced by
my years of experience with the company tells me that I can invest my
time in other efforts that are bound to yield more value.
I gave my feedback. It was dismissed. I went back to work with Rails
with ever more confidence that I made the right technology decision -
a decision based on factors that I have yet to see the players on
Microsoft's side get hip to yet.
And I will absolutely reserve the right to wag a prescient and knowing
finger at the result if I call it true.
I'm open to being pleasantly surprised, however.
Scott Bellware
of Rails. Why not base ASP MVC's design philosophy on the philosophy
of a framework that has already explosively won the hearts and minds
of a larger developer population?
Phil Haack
aware of are the following:
1. Don't require [ControllerAction] to indicate a controller action.
2. Don't require calling RenderView. Do it automatically based on
conventions.
Am I correct?
Here's the current thinking on these two:
1. I actually lobbied for this when I joined, but now agree that there
are *good* reasons not to make every public method on a controller web
visible. I'm all for convention and a bit of magic, but when magic
exposes something without your knowledge, that can be dangerous for
security reasons. Besides, we're not alone in thinking this. There have
been those in the rails community thinking along the same lines:
http://www.bofh.org.uk/articles/2006/08/03/ruby-til-6
While you might disagree with this choice, I hardly think it's a black
or white decision. At the very least, we haven't prevented you from
doing something productive.
2. Another item I lobbied for based on my rails experience, but there is
also "industry" experience that points to requiring "RenderView" being
called as they do in Django and other Ruby web frameworks.
For example, the following scenario is problematic if the rendering
occurs *after* the action method completes:
[ControllerAction]
public void SomeAction()
{
using(IDisposable resource = DIFramework.GetService())
{
//Bunch of logic.
RenderView("SomeView", resource.Data);
}
}
Sure, I could have the controller implement IDisposable and have the
resource passed in via the controller constructor, but that's pretty
ugly IMHO if this is the only action method of several that need this
disposable resource.
Another scenario is unit testing. Take the following example:
[Test]
public void SomeTest()
{
SomeController controller = new SomeController();
controller.Index();
//Assert that the correct view is rendered.
}
If we don't make calling RenderView explicit, you know have to add extra
code to that unit test to set up whatever context actually invokes the
RenderView method. Kind of a pain if you ask me.
Personally, I'd prefer to have something like RenderView(ViewData) which
selects the view name by convention. So calling RenderView is explicit,
but the choice of view is by convention with the option to override.
The thing about convention over configuration is that it is not somehow
sacred. There are cases where convention becomes "magic" and isn't the
best choice. There are cases where convention makes the experience of
development sublime. Making those choices is the goal of the designer
and it is an art, not a science. These choices won't make everyone
happy. Sorry.
I hardly think that when the choices are made with a lot of thought and
good solid reasoning, that it should be characterized as intellectually
bankrupt. Rails is quite successful, and believe me, it is a source of
inspiration. But it should hardly be put on a pedestal as the One True
Design.
Phil
Phil Haack
IronRuby to mature. Why should we recreate what is already out there?
As for "the larger developer population", do you have numbers to back
that up? Seriously, I've been trying to get numbers on the various
frameworks so I understand what we're talking about. I have no idea how
many rails devs vs php devs vs structs vs ASP.NET devs there are. Would
love to see that data.
Phil
Stuart Laughlin
>
> If you want rails, use rails. If you want rails on .NET, wait for
> IronRuby to mature. Why should we recreate what is already out there?
>
I'm not trying to be provocative or unkind, but isn't that precisely
what ASP.Net MVC is doing? (i.e. recreating what is already out there
in MonoRail)
--Stuart
Scott Bellware
harvest the reasons for the framework's success, and apply them to
your work.
As for numbers, I don't have that data. However, as soon as Monorail
and Subsonic get popular enough to have developer conferences on the
order of the Rails conferences, I'll start making some rudimentary
extrapolations.
If you're including every old ASP.NET dev in your target market, I
think you're going to end up squandering opportunities to really serve
the kind of devs interested in MVC.
Phil Haack
eh? ;) Good question.
Yes and no. Yes, we're recreating something similar to what's already
out there. No, it's not an exact recreation. We have different design
goals and philosophies towards design than the Monorail team and those
choices we make at every point will shape ASP.NET MVC to be something
different.
What a waste of effort to create the same exact thing.
When you look at Django and Rails, you could ask the same question. Why
build one when the other was already out? Why not just do a port to the
language of your choice?
I think that's kind of a mistake. I think rails is so successful in part
because of its attention to Ruby. In other words, ruby is a nice
productive dynamic language with a rich set of idioms and Rails is
optimized for that style of development.
ASP.NET MVC will be optimized for a slightly different style of
development and will leverage ASP.NET (membership, security,
scalability, etc...) and rich tool support (VS 200?).
There will be many who think it fits them and will be drawn to it. There
will be many who reject it and will choose other platforms or stick with
WebForms. I'd expect no less.
My goal and hope is that it will stand on its own as a great, clean,
extensible, productive, fun platform for building web apps that fit this
model of development.
Phil
Scott Bellware
On Nov 28, 2007, at 3:36 PM, Phil Haack wrote:
> there are *good* reasons not to make every public method on a
> controller web visible.
Sure. But there are *no* good reasons to have public methods on
controllers that aren't in fact controller actions.
> There have been those in the rails community thinking
> along the same lines:
There are skilled pilots who have died in crashes as well. You guys
are in a position to provide a solid practice guidance offering with
the framework, and build a user culture that is confident and
knowledgeable.
> At the very least, we haven't prevented you from
> doing something productive.
You'd be making me add irrelevant line noise to my codebase. That's
not productive.
Make the framework based on Convention over Configuration by default,
and make the safety edges stuff an add-on. You're not giving devs the
option of removing the training wheels. You're forcing them to fit
the framework with an extra-large rear wheel so that the training
wheels don't reach the ground.
> Sure, I could have the controller implement IDisposable and have the
> resource passed in via the controller constructor, but that's pretty
> ugly IMHO if this is the only action method of several that need this
> disposable resource.
You gotta be kidding me. That's a horrible design.
This is a problem solved by using good layering and dependency
practices. Again, the framework is a much lessor offering without the
practice guidance.
> If we don't make calling RenderView explicit, you know have to add
extra
> code to that unit test to set up whatever context actually invokes
the
> RenderView method. Kind of a pain if you ask me.
The unit testing friction is there to tell you that your design is
wrong, not that the framework needs to be changed to support poor
design.
> There are cases where convention makes the experience of
> development sublime. Making those choices is the goal of the
designer
> and it is an art, not a science. These choices won't make everyone
> happy. Sorry.
You don't have to make those choices from scratch. You can just look
to the Rails community and wonder at all the little decisions the
Rails team makes to make the framework so adoptable and usable.
> Rails is quite successful, and believe me, it is a source of
> inspiration. But it should hardly be put on a pedestal as the One
True
> Design.
Indeed. I'd like to see you do something for .NET developers that
improves on Rails. It appears to me that you're not willing to take
the wisdom of the community at large in your decision though, and that
you're banking on theory.
If you're right in the end, I'll sing the praises of the framework
with verve and glee.
Phil Haack
with verve and glee.
Bring your banjo. ;)
Phil
Scott Bellware
me to have to spend my free time writing Rails CoC policies, I buy a
banjo and learn to play a song of your choosing!
Ayende Rahien
I disagree. MonoRail takes a lot from Rails, but it is not reproduction, nor are we trying to get something like a feature parity, or something like that.
We got a lot of ideas, but the basic architecture and directions are completely different.
Ayende Rahien
[ControllerAction]
public void SomeAction()
{
using(IDisposable resource = DIFramework.GetService())
{
//Bunch of logic.
RenderView("SomeView", resource.Data);
}
}
This is an anti pattern, IMO. It is not something that you want to do.
It is also not something that I have ever seen the need to. The only thing where I can think about it being useful is if you want to pass a IDataReader directly to the form. If you do, this is a mistake.
Try somtehing like this:
using(IDisposable resource = DIFramework.GetService())
{
PropertyBag["data"] = new StringReader(resource.Data.ReadToEnd());
}
Sure, I could have the controller implement IDisposable and have the
resource passed in via the controller constructor, but that's pretty
ugly IMHO if this is the only action method of several that need this
disposable resource.
Another scenario is unit testing. Take the following example:
[Test]
public void SomeTest()
{
SomeController controller = new SomeController();
controller.Index();
//Assert that the correct view is rendered.
}
You test that the selected view is the one by convention, or you don't test that, because there is no behavior there.
You can do it easily by checking that the view doesn't change it.
[Test]
public void SomeTest()
{
SomeController controller = new SomeController();
controller.Index();
Assert.AreEqual("foo", controller.SelecteViewName );
}
Ayende Rahien
Ayende Rahien
> what ASP.Net MVC is doing? ( i.e. recreating what is already out there
> in MonoRail)
>
>
> --Stuart
>
> >
>
Phil Haack
do. Seeing you play the banjo singing our praises is a lot of motivation. ;)
I'm not yet convinced about baking an implicit call to RenderView. I'll
chew on that one.
As I said before, I personally wanted to get rid of the
[ControllerAction] requirement. I do think there was a lot of thought
put into keeping it there and that was the point I was making in this
thread. I still fail to see that decision as "intellectually bankrupt".
It just optimizes for a different constraint - the constraint of
security over productivity. There is a real concern over the security of
implicitly making every method web accessible. On the face of it, it
defies the principle of reducing attack surface and requiring opt-in.
Of course, on the other face of it, implementing IController or
inheriting from Controller could be seen as "opting-in". This is what I
argued when I first played with the framework.
While I didn't see the ControllerAction attribute as necessary, in
practice, it didn't bother me so much because of intellisense makes it a
lot less real typing. ;) But that doesn't solve the "clutter" issue, I know.
In any case, we're all theorizing here. The CTP should be out sometime
in December. Once it's out, you'll get a chance to play with it for real
if you want to and that would be a great time to critique the design and
submit Connect feedback (we do go through it all). Your feedback will
have more impact when it's based on real usage of the bits.
Phil
sbohlen
> It just optimizes for a different constraint - the constraint of
> security over productivity. There is a real concern over the security of
> implicitly making every method web accessible. On the face of it, it
> defies the principle of reducing attack surface and requiring opt-in.
I think the point here is that for the monorail folks the PUBLIC
access modifier in their controller class IS their opt-in (by
CONVENTION). They are simply arguing that PUBLIC means just that:
PUBLIC, and in a controller that means its a callable action. Anytime
you choose to expose a PUBLIC method, BY CONVENTION that means that
its callable from a REST-style URL.
You seem to be arguing that there needs to be an explicit
CONFIGURATION (the extra attribute) and they are saying "We are
already being explicit -- we made the method PUBLIC, damnit". I
really don't understand why you see the need to require TWO opt-ins
when one in this case seems to be enough for everyone. For you,
PUBLIC + the extra attribute = a callable action but for the rails
folks PUBLIC = a callable action all by itself. That's the
'convention' and it doesn't seem to me any more of a 'danger' to any
developer with or without the attribute; both mean the dev is opting
to expose the method as an action and both can be equally misused
IMHO.
-Steve B.
Scott Bellware
Scott Bellware
On Nov 28, 2007, at 3:53 PM, Phil Haack wrote:
> I think rails is so successful in part because of its
> attention to Ruby. In other words, ruby is a nice
> productive dynamic language with a rich set of idioms
> and Rails is optimized for that style of development.
Rails is also successful because of Rails' idioms like principle of
least surprise and convention over configuration.
> ASP.NET MVC will be optimized for a slightly different style of
> development
Could you point to examples of who this style of development will be
applicable to?
Phil Haack
> Of course, on the other face of it, implementing IController or
inheriting from Controller could be
> seen as "opting-in". This is what I argued when I first played with
the framework.
I was merely making the point that there is some validity to the other
view point. The analogy (and yes, no analogy is perfect) is that when I
enable IIS on my server, that shouldn't opt me in to have every possible
extension available on the web (.printer anyone?)
Again, I initially argued for not having the attribute. My point in
bringing up the alternate viewpoint is to point out that the argument
for having the attribute is not without some merits. I find it useful in
a debate to look for the merits in the opposing viewpoint rather than
simply dismissing it.
Phil
Scott Bellware
would be a fine argument, but you're unleashing a new framework in the
Microsoft world, and some of the stewards of a movement to bring more
responsible action to software design and development who have real
experience with these frameworks are asking you to consider another
direction.
In the end, I understand that we can make the framework behave the way
we want by replacing the out-of-the-box stuff. But, we gotta sink yet
more of our free time into bringing this to life. It's hard to fit
that in while we're still working on helping the community recover
from the last developers-don't-need-to-think-oriented Microsoft
development tool.
For once, it would just be nice to see Microsoft-ish folks deliver an
out-of-the-box experience that was Positive by Default rather than For
Dummies by Default.
Phil Haack
wrong, not that the framework needs
> to be changed to support poor design.
Could you elaborate on this?
Phil Haack
people "intellectually bankrupt" because they don't agree with you isn't
really a great way to ask anyone to consider a new direction.
Not to mention that it is possible to disagree on a design/design
philosophy and yet see merits in the other design and not resort to name
calling because we don't agree.
Out of curiosity, do you have "real experience" building Django apps?
The reason I ask is they've chosen a philosophy that everything should
be explicit vs the rails philosophy that focuses more on conventions.
Would you consider the Django approach to be "intellectually bankrupt"?
I remember reading a DHH quote (can't find it, so take it with a grain
of salt) in which he said something to the effect of if Django had been
around, he wouldn't have needed to create rails.
I see ASP.NET MVC as taking inspiration from both of these frameworks,
while trying to be its own thing. It's not without its flaws, for sure,
but we've not even released our first CTP yet.
Phil
Scott Bellware
Precisely: 'The stock "you can write your own policy plug-ins for
Convention over Configuration" is an intellectually bankrupt position.'
I attacked the idea. If you are identified with your ideas... well...
that's your cross to bear.
> isn't really a great way to ask anyone to consider a new direction
Nothing in my experience with Microsoft suggests that there's any
reason to believe that a framework or product design will change once
it's upper managers have become attached to their ideas about it.
> Out of curiosity, do you have "real experience" building Django apps?
No. Do you? I'd love to hear your experience with it if you have,
but if you're just borrowing from someone else's experience to justify
some of ASP MVC's design decisions, I don't really care to hear it.
I'm talking to folks in the local Rails community local Rails
community who are using Django. Trying to pick up as much as I can
about it and understand the trade offs and advantages. That's the
extent of it for me at this point.
> The reason I ask is they've chosen a philosophy that everything
should
> be explicit vs the rails philosophy that focuses more on conventions.
> Would you consider the Django approach to be "intellectually
bankrupt"?
I can't speak to it until I have more meaningful experience.
I understand that things in Django are done explicitly. If the
reasons for it's designers' choices of explicitness are the same as
yours', then I don't agree with it for the same reasons that I don't
agree with the choices made for ASP MVC. I can't say whether it's
intellectually bankrupt until I have more substantive understanding,
but I wouldn't be afraid to say that it was if I ended up feeling that
way. It depends on the motives.
The motives behind the choices for the ASP MVC framework in my opinion
are expressive of a consistent pattern of CYA-oriented, craven
decisions that end up setting the development community back.
> I remember reading a DHH quote (can't find it, so take it with a
grain
> of salt) in which he said something to the effect of if Django had
been
> around, he wouldn't have needed to create rails.
Did he say this specifically in regards to an appreciation for its
explicitness? That would be interesting. Id' like to hear more about
that if its the case. I haven't found much to disagree with DHH about
yet... although I haven't agreed with everyone on the Rails core team
about all things software development.
> It's not without its flaws, for sure,
> but we've not even released our first CTP yet.
What difference does that make? Between you, me, the lamp post, and a
couple million Microsoft developers, CTP usually means that Microsoft
is open to responding to feedback that validates the directions that
it has already committed to.
We need to start virtual riots before softies are willing to take
input seriously, and even then, when it doesn't fit the model, the
stock answer usually has something to do with it being too late in the
cycle to consider new changes.
Feedback via Connect indeed. I don't think you realize how much of an
insult Connect is to folks who work hard to carve out time in their
lives to stay connected with real people in real communities through
real relationships. There's a reason why softies always gotta say,
"we really do review the feedback on Connect." The faith has left the
building. Reviewing feedback doesn't matter one bit. What counts is
the actions that are taken based on feedback, and the agility with
which they're taken.
So this has been eating me all night...
You said you came into the project debating for Convention over
Configuration in the framework. Do you make the design decisions, or
are they made above you?
Scott Bellware
On Nov 28, 2007, at 9:02 PM, Phil Haack wrote:
> Keep in mind that calling
> people "intellectually bankrupt" because they don't agree with you
isn't
> really a great way to ask anyone to consider a new direction.
Wait a minute... does this mean that if I talk pretty that you'll take
my issues under deeper consideration? Are you saying that the merit
of ideas are evaluated as a function of the petitioners willingness to
kiss up? Man, if that's the case, we should just cut any future
losses right now and agree that we've got nothing to talk about.
Scott Hanselman
Scott Bellware
Ayende Rahien
On Nov 28, 2007, at 9:02 PM, Phil Haack wrote:
> Keep in mind that calling
> people "intellectually bankrupt" because they don't agree with you
isn't
> really a great way to ask anyone to consider a new direction.
Wait a minute... does this mean that if I talk pretty that you'll take
my issues under deeper consideration?
Most probably.
Are you saying that the merit
of ideas are evaluated as a function of the petitioners willingness to
kiss up?
No kissing up is involved at any stage.
But, there is a no issue with disagreeing with someone while being polite.
Man, if that's the case, we should just cut any future
losses right now and agree that we've got nothing to talk about.
Or, we can have a mature conversation where we all respect each other and can disagree in a manner that keeps the discussion open.
Ayende Rahien
When I manage to get to the people that matter, I usually hear a very polite response, we even have a good conversation, but I haven't seen results.
Nevertheless, I don't think that this excuse a lack of manners. From experience, you can be very firm without resorting to unmannered speech.
Connect is a pain point, sure. But even just normal communication.
Scott Bellware
On Nov 29, 2007, at 1:18 AM, Ayende Rahien wrote:
> Nevertheless, I don't think that this excuse a lack of manners.
> From experience, you can be very firm without resorting
> to unmannered speech.
I have a broader view of the class of things where mannered-speech
resides.
Microsoft treats the world with disrespect through the quality of its
software product, and its choices in the past to employ illegal
business activities that resulted in fewer choices for its audience.
From me, Microsoft gets what it gives. That seems fair.
Scott Hanselman
Michael Kelly
contributions to this discussion. In particular, I want to thank Phil
for so boldly stepping into the fray and conducting himself with
thoughtful equanimity, and Scott Bellware for taking a strong position
and defending it with clarity and vigor.
The discussion has been quite useful for me. It has helped to refine
my own opinions. Below are some of my conclusions. I offer them as
evidence of the value I've gotten from the discussion, and encourage
you to challenge them further.
1. On the specific issue of the ControllerAction attribute, I can't
honestly say that it's a deal breaker for me either way. In an earlier
discussion (http://groups.google.com/group/altnet/browse_thread/thread/
4df6246170675034) I stated that I preferred requiring the attribute
over the Rails approach. For me, making a method "public" has a very
specific and limited semantic significance--it says that the method is
available to other classes. It feels like a side-effect for it to also
mean that the method is available via an HTTP request. I'm simply not
used to thinking of the meaning of "public" as contextual (i.e. in the
context of the Controller it also means browser accessibility). But
linguistically, meaning is frequently contextual. I suspect that this
is something I could learn to love. It also took me a while to decide
that square-toed shoes were attractive. :-)
2. On the issue of Convention vs. Configuration, I've come to to
believe in neither (or perhaps, both). The point is to reduce the
number of discrete mandatory decisions that must be made by developers
in their efforts to provide value to customers, and to establish
consistency within and across applications. Conventions can be useful
toward this end, as long as the conventions remain simple enough to
learn, remember, and apply. And it appears to me that the same can
actually be said about configuration. In some respects, the
"Convention over Configuration" equation reminds me of the agile
manifesto's principles: "Individuals and interactions over processes
and tools", "Working software over comprehensive documentation",
"Customer collaboration over contract negotiation", and "Responding to
change over following a plan". It isn't that the things on the right
side of the equation are inherently bad, it's just that agile
methodologies have a preference for the things on the left. We're
still expected to thoughtfully consider both sides of the equation,
and select an approach that meets the needs of the situation before
us.
3. I originally conflated "Convention over Configuration" with MS
MVC's ORM and unit test framework agnosticism, and I now believe that
these two items (while related) really need to be considered
separately. In truth, I'm more concerned about the impact of the
framework's agnosticism on developer productivity than I am about the
specific balance the framework makes between Convention and
Configuration. By definition, the agnosticism means more non-value-add
technical decisions and less consistency across applications. In
addition, it significantly hampers the development of Rails-style
plugins if you can't assume a specific ORM and unit test framework.
These plugins typically include views, controllers, and models, along
with an extensive suite of unit tests. The plugins provide whole
vertical slices of functionality that can be dropped into an
application with a modest amount of connective tissue, and the
supplied unit tests make the work of modifying the functionality when
necessary both safer and faster. While I appreciate why Microsoft
wants to create an open framework, I really want someone to take a
stand. I want someone to fill in the holes and provide a complete and
compelling solution that engenders a significant following that
produces a rich repository of plugins.
4. Finally, and I'll address this to Ayende as the only Castle Project
representative on the thread, I wonder if embracing and extending MS
MVC doesn't actually make it so the Castle Project can deliver more
value. If they simply accept Microsoft's solution for the views and
controllers, doesn't this free the Castle Project developers to focus
more effort on porting more features to NHibernate, building out their
ActiveRecord solution, developing a migration solution, solidifying
and extending ActiveWriter, producing VS templates inspired by Rails
generators, developing a plugin solution (and perhaps hosting the
repository), and God knows what else?
Well, there it is. And once again, much thanks to everyone who's
participated.
-=michael=-
Ayende Rahien
More choices generally means better options for the developer. That assumes that I can make this choices implicitly, not explicitly. If I need to make too much of them upfront, it is a problem, so far, I don't like the MS approach, but I don't see it hitting that point.
The following represent my own opinion, you can read the official Castle statement about MS MVC here http://www.castleproject.org/
4/ Castle MonoRail is a mature project. It is has proven itself out there, in the field, against most of what people could throw at it. The MS MVC stuff has not. The MS MVC stuff doesn't really exists yet in a concrete form, for that matter.
To suggest that we should re-base MonoRail on top of MS MVC is an unwise decision, in my opinion. It makes several broad assumptions about the result of such a thing. For a start, it assumes that the actual infrastructure
code is a hindrance to the development of further MonoRail features.
In actuality, this is a stable code base, we have very few reasons to go there and muck with things. It wouldn't free up anyone's time, but it would make it a really big change for no apparent benefit.
Another issue is with the ability to control what is going on there. With all due respect to Phil, and as responsive to community feedback he would like to be, I can get things done faster if I have more control.
This means that MonoRail having control over the entire stack is an important factor in our abilities to make changes to it.
From my own view point, MS MVC is a sign of a change in the way Microsoft operates. I would like to see it spread toward more parts of the company. Having people that understand the way I would like to work, and having them in position to actually do something about this is critical.
IHttpContext, anyone?
In addition to that, the mere fact that MS has gotten Hammett to come and take a look at MS MVC helps a lot in terms of building confidence in the platform, IMO.
I will have to admit that I am having a crisis of faith right now with regards to the MS MVC platform. On the one hand, I have seen too many MS projects that looked really promising on the surface and had a rotten core. On the other hand, all the indication we got so far is that it is going in the right way.
I am pretty sure that the marketing people will make me livid, no matter what. I am also pretty sure that the name is going to suck, probably they will end up calling in Microsoft Innovative Dynamic Shape Vista SP2 Supervisor Inspector Community Edition 2008.
So to surmise and already too long reply, I care mostly about the change that I see in MS recently, and I care deeply that the MS MVC platform will be a good solution, because my main concern is not what people are using, but that they are using tools and approaches that supports maintainable software practices.
Gentleman, I want to thank each and every one of you for your
contributions to this discussion. In particular, I want to thank Phil
for so boldly stepping into the fray and conducting himself with
thoughtful equanimity, and Scott Bellware for taking a strong position
and defending it with clarity and vigor.
The discussion has been quite useful for me. It has helped to refine
my own opinions. Below are some of my conclusions. I offer them as
evidence of the value I've gotten from the discussion, and encourage
you to challenge them further.
1. On the specific issue of the ControllerAction attribute, I can't
honestly say that it's a deal breaker for me either way. In an earlier
4df6246170675034) I stated that I preferred requiring the attribute
over the Rails approach. For me, making a method "public" has a very
specific and limited semantic significance--it says that the method is
available to other classes. It feels like a side-effect for it to also
mean that the method is available via an HTTP request. I'm simply not
used to thinking of the meaning of "public" as contextual ( i.e. in the
Michael Kelly
Ayende in these conversations over Oren).
On Nov 29, 3:53 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> 3/ Assuming nothing is broken with the impl, you should be able to create a
> DLL that contains everything in a vertical slice. That includes data access,
> controllers and views. You can certainly do that with MR, and I believe that
> it will possible with the MS stuff (can we get a better name?).
tremendous amount of sense, but not the first thing I thought of. It's
not the Rails approach. In Rails, the plugins actually become part of
your code. You run a script and it installs itself in the directory
structure established by Convention. I have to admit that I've been
liking the fact that the plugin installs itself in this fashion. It's
given me a greater sense of ownership over the this code, and made me
feel freer to modify it to strengthen the quality of the integration
with my app. Of course, I've been conscious of the difficulty this
will create should I decide to install an upgraded version of the
plugin, but on the whole I've preferred deep integration over clean
separation. I'll have to give this some thought.
> More choices generally means better options for the developer.
framework. I just want choices out there that remove the choices. :-)
>
> The following represent my own opinion, you can read the official Castle
> 4/ Castle MonoRail is a mature project. It is has proven itself out there,
> in the field, against most of what people could throw at it. The MS MVC
> stuff has not. The MS MVC stuff doesn't really exists yet in a concrete
> form, for that matter.
> To suggest that we should re-base MonoRail on top of MS MVC is an unwise
> decision, in my opinion. It makes several broad assumptions about the result
> of such a thing. For a start, it assumes that the actual infrastructure
> code is a hindrance to the development of further MonoRail features.
> In actuality, this is a stable code base, we have very few reasons to go
> there and muck with things. It wouldn't free up anyone's time, but it would
> make it a really big change for no apparent benefit.
> Another issue is with the ability to control what is going on there. With
> all due respect to Phil, and as responsive to community feedback he would
> like to be, I can get things done faster if I have more control.
> This means that MonoRail having control over the entire stack is an
> important factor in our abilities to make changes to it.
I on the project.
Thanks again,
-=michael=-
Phil Haack
stance and reject ideas initially when faced with vitriol and venom.
Personally, I try my best to focus on the facts and ideas in discussion,
or I wouldn't still be here. But anyone who says they completely operate
in the world of ideas and logic and never let emotion sidetrack the
conversation, even for a moment, is lying or is emotionally disconnected
to a frightening degree. After all, this very conversation has been
sidetracked by the forces I'm talking about.
Phil Haack
weeks only), *I* am not Microsoft. I personally don't have a record of
producing offensive software. So I *will* ask that you keep the
discussion with me civil as one person who's been involved in the
community to another.
Passionate heated discussions are fine, but even those can be conducted
without antagonism.
Phil Haack
change in thinking, at least in the Developer Division. I can't speak
for other divisions. One thing I've noticed since arriving is that
groups are starting to become "test infected", though it's a slow
process. I don't know the exact number but I believe the MVC framework
has close to full test coverage. Much over 90% I think. Don't quote me
on that. ;)
One thing we've been focused on is extensibility at all levels of the
stack. Hammet built an NVelocity view engine in no time. It's not the
same level of control that an open source project provides, but it's a
lot more than is usual from MS.
That level of control is one key advantage of Monorail as an open source
project. Another advantage is that monorail can serve platforms that
ASP.NET MVC probably won't serve any time soon, such as earlier versions
of ASP.NET.
One other advantage of an open source project is that with a motivated
community, they can provide releases much more often than we can and
they typically target a more focused or different audience. I'm not sure
that this will be a zero sum game. The analogy I use is that Subtext has
continued to thrive despite Community Server because in large part we
serve different interests and markets. Of course Telligent doesn't have
the size or influence of Microsoft, so I understand the shortcomings of
that comparison.
Phil
> On 11/29/07, *Michael Kelly* <m.sean...@gmail.com
Michael Kelly
> Nice. Thanks Ayende for the thoughtful reply (I assume you prefer
> Ayende in these conversations over Oren).
>
> On Nov 29, 3:53 am, "Ayende Rahien" <aye...@ayende.com> wrote:
>
> > 3/ Assuming nothing is broken with the impl, you should be able to create a
> > DLL that contains everything in a vertical slice. That includes data access,
> > controllers and views. You can certainly do that with MR, and I believe that
> > it will possible with the MS stuff (can we get a better name?).
>
> Hmmmm.... Dropping plugins in as DLLs, of course! It makes a
> tremendous amount of sense, but not the first thing I thought of. It's
> not the Rails approach. In Rails, the plugins actually become part of
> your code. You run a script and it installs itself in the directory
> structure established by Convention. I have to admit that I've been
> liking the fact that the plugin installs itself in this fashion. It's
> given me a greater sense of ownership over the this code, and made me
> feel freer to modify it to strengthen the quality of the integration
> with my app. Of course, I've been conscious of the difficulty this
> will create should I decide to install an upgraded version of the
> plugin, but on the whole I've preferred deep integration over clean
> separation. I'll have to give this some thought.
closure, I'd like to wrap with these thoughts.
I've been trying (w/o much success) to stress the importance of the
plugin architecture to Rails' success, and to suggest that successful
imitators will need to provide something similar. Ayende suggested
that they could be wrapped as DLLs, which is true, but I believe that
this misses something essential. Let me take as an example the Rails
plugin known as Acts_As_Authenticated (you'll find it described here:
http://technoweenie.stikipad.com/plugins/show/Acts+as+Authenticated).
This plugin handles account creation (including email confirmation),
login, logout, change password, forgotten password, etc. Included in
the plugin's model is a User class. But of course! How can you
possible have views and controllers with this kind of logic without
referencing the user? But a User class is a core entity in any
application. So core, in fact, that it feels odd to me to have it in
separate DLL. What's more, in my own Rails application I have modified
the User class in a variety of ways to meet my specific needs. In a
very real sense, Rails plugins are units in the Borg--they get
assimilated. If you take a look at the link above, you'll find that
the documentation is instructions for the base assimilation along with
a variety of options. So, I believe there is an implicit value in
Rails plugins that might be characterized as "Assimilation over
Separation", and shouldn't be ignored.
-=michael=-
Phil Haack
interesting topic in its own right.
I think this is where true mixins would be nice as Ayende has alluded to
in a recent blog post, assumisng you could mix two separate classes into
one in which you don't have the code for either.
The same thing sort of happens with MembershipProvider though. If you
buy into the membership provider, then you need to assimilate it all. In
C# 3.0 you can use extension methods to add stuff to the MembershipUser
class, for example. Perhaps not as ideal as having the user class as a
script file that you can edit as you would in rails.
Of course, in rails, what do you do when another plugin wants its own
"user" class? You have the option of merging the user classes and doing
a search and replace, but that can be a pain for the upgrade path. I'd
probably end up creating various adapters for the various user classes,
not wanting to change the core implementation.
Ayende Rahien
MR can works with several view engines at once, and assuming that you know how to merge the stuff to the project, there is nothing that prevents a source dist
Michael Kelly
what I see as the requirements:
1. It should be blindingly easy to create a plugin. Ideally, a
developer should be able to say to themselves, "Hey, this set of
views, controllers, and models might be useful to someone", and
package it as a plugin within an hour.
2. It should be blindingly easy to install a plugin. And once
installed, it should just work without any additional configuration
hassles (e.g. no additional database configurations).
3. Plugins should be completely customizable. The developer should be
able to easily add or modify functionality in the plugin at any level:
view, controller, or model.
4. There should be a high degree of consistency between plugins. If a
developer knows how to install one plugin, then they know how to
install all plugins. In addition, if they know the tools to customize
one plugin, then they know the tools to customize all plugins.
5. The classes of plugins (or at least, the functionality available
from those classes) should appear to exist in the namespace of the
developer's application.
6. The unit tests delivered with plugins should run naturally as part
of the suite of tests for the developer's application. And the tests
should be as customizable as the code they test.
7. And just to make it interesting, there should be a simple and fool-
proof means for upgrading the plugins.
I've asked for a lot here, but hey, I'm the customer. :-) Feel free to
push back on any of the requirements.
BTW Ayende, did you intend to revert Phil's change to the subject of
the thread? Or was that a side-effect of replying to a previous post?
-=michael=-
On Nov 30, 3:18 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> Well,
> MR can works with several view engines at once, and assuming that you know
> how to merge the stuff to the project, there is nothing that prevents a
> source dist
>
Ayende Rahien
[Mixin(typeof(IAuditable), typeof(AuditableImpl)]
public class User
{
public IAuditable Audit
{
get { return (IAuditable)this; }
}
}
About the rest, I am in favor of doing it with the support of the above code, and an external DLL that you can just drop in the bin folder and register, nothing more.
Ruby & CLR design patterns are different, because they have different constraints, I don't think we have to do it with the same way.
The Provider is a bad example, actually, because it ties you to the original contract. I like it more when I can inherit and extend that. Static gateway make it PITA.
Scott Bellware
Scott Bellware
> of the suite of tests for the developer's application. And the tests
> should be as customizable as the code they test.
I'm interested in testing the code that I wrote that uses plugins, not
the plugins themselves. I'm interested in plugin tests only when I'm
working directly on the plugin.
I'f I have code that uses a plugin, and that code passes all of its
tests, I'm assured that the parts of the plugin of interest to me do
indeed work. The only way I can get code into my app that uses parts
of the plugin that I haven't verified transitively would be to
introduce new app code that doesn't have tests.
I don't want or need the tests results for third party materials in my
app's test results, and I don't want to augment my app's build time by
running tests on third party code.
Scott Bellware
The word "attachment" comes up often in community dialog around the
fire in alt.net circles. In fact, it was a subject addressed in the
Behavior Driven Design workshop that JP and I gave in Vancouver on
Friday. I'm not making any claims for a requirement for perfect
practice in detachment, but many of us do at least try to practice
awareness of it so that we can have some small chance of surmounting
attachment's deleterious effects.
In that regard, I don't know how valuable is the "frightening degree"
part of your characterization of what I'd think of as an otherwise
noble goal that is often part of the alt.net's community's
conversation. If you're taking about it from the perspective of the
values I see expressed more in the alt.net community versus the MSDN,
then it holds for me. Otherwise, what you might experience as
frightening, I might experience as normal.
We're all predisposed to attachment, and I for one have no qualms with
engaging with whole heart in the conflicts that come from attachment,
but I try to exercise my willingness to enter into conflict as
consciously as possible, and to examine the emotional content of my
responses in respects to whether I'm merely being hooked by emotions
caused by attachment.
I don't expect you to be a robot, and I have no issues with you as a
person and as a human being and a member of the development community
at large. I do have issues with your unwillingness to stand up to
Scott Guthrie et al and fight for contemporary approaches for MVC that
they struggle with because of their own attachment.
So, I see the design decisions leading away from Convention over
Configuration as intellectually bankrupt if they're governed by
attachment rather than rationale. There's too much fear feeding the
ASP .NET MVC framework for me to allow you the benefit of the doubt.
I've seen fear and attachment on your part and on Scott Guthrie's
part, and I believe that this frame of mind is on line when design
decisions are being made for the framework.
Scott Bellware
speak to the community. Their experience of your software will be a
part of their experience of the dialog with you.
My experience of what you're planing to deliver to the community - as
I understand what you'll deliver - suggests that the civility of the
conversation has already begun with something of an insult.
I am not talking about your track record here. I'm talking about what
you're doing know, and the product that you'll be delivering next
year. You now dance to someone else's tune. There's no reason for
the community to assume that you'll be able to do in the future what
you've been able to do in the past.
Based on what you've already said about the decisions for the
framework that are being made above you, there's already some reason
to believe that your future work product will not be executed with the
same vision as your past work product.
And straight up, folks who join Microsoft tend to loose their voice.
The way I see it, the community has a limited window of time to have
substantive conversations with you before you stop hearing us. Who
knows, you might be different, and so may Scott Hanselman, but
yesterday's weather doesn't make it a safe bet.
Look, I WANT to get behind an MVC framework from Microsoft. You're
simply not giving me something that I can get behind with a clear
conscience, and I'm not the only visible and vocal alt.net guy with
the same concern. And the reasons why this is happening seems to be
yet more same-old-same-old from Microsoft on politics and fear.
You're on the van. There's no one in a better position to fight for
good things and for changes than you.
This may not be the hill that you choose to die on, but if you choose
not to fight, it may be the hill that your credibility is critically
wounded on.
The campfire discussions at DevTeach this past weekend in regards to
the ASP .NET MVC framework weren't sunshine and roses. Your product
has an iffy confidence vote from the group of people who may either be
your strongest cheerleaders or your strongest detractors. The one
thing you can count on from us is our lack of indifference.
There are a good number of visible and vocal people who doubt that
you'll be able to pull off a framework that will satisfy the
expectations of folks who have enough time on task with the style of
work inherent in MVC framework use to have built real and present
expectations.
In regards to the core alt.net community, you've got one play
available to you: you gotta hit it outa the park. Or, you've gotta
make it clear that the community with the single greatest number of
active MVC users isn't the target audience for an MVC framework from
Microsoft.
If the alt.net community is an important voice for your product and an
important adoption audience for your product, you've gotta treat us
the way that our value systems and methods guide us in treating our
own customers. There's no reason why we should expect less from
Microsoft than we expect from ourselves.
Ayende Rahien
Phil Haack
> Scott Guthrie et al and fight for contemporary approaches for MVC that
> they struggle with because of their own attachment.
You've made a lot of assumptions in that statement. Decisions are made
as a team and I haven't said who fought for which decisions. And you've
assumed I've given up the fight for anything. Perhaps I was unclear, but
my point this whole time was there is a rationale behind the current
decisions being made, not that the decision is final. I see that there
are two sides to the debate and both have very good valid ponits. I
thought Michael Kelly did a great job in this forum of describing a
great rationale to keeping it. I felt I've put forth good arguments for
getting rid of it.
One of my goals is to listen to the community and fight for the choices
I think are right. That's why I'm still here, still responding, still
reading. I think it's helped in formulating new arguments I will put
forward.
Of course, this particular community is not the only community to listen
to. It's not the only one with valuable insight and feedback. And others
who do have such insight and experience don't necessarily agree with
this community on every single issue.
Phil
Michael Kelly
"Assimilation over Separation". Mixins play a huge role in their
plugin strategy, and if you can achieve separation while still
enabling rich customization then I'm with you on not testing third
party code.
I guess this leaves us where Ayende has been trying to move things:
how can .net support mixins?
-=michael=-
Ayende Rahien
The other ways are IL Weaving and Dynamic Mixins.
> hassles (e.g . no additional database configurations).
Michael Kelly
-=michael=-
On Dec 3, 8:32 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> Compiler magic is the preferred way. I can probably hack the mono compiler
> to do this, but since I can do this in less than 50 lines of Boo code, so I
> don't think I'll bother.
> The other ways are IL Weaving and Dynamic Mixins.
>
Scott Bellware
On Dec 3, 2007, at 2:51 AM, Phil Haack wrote:
> Of course, this particular community is not the only community to
> listen to. It's not the only one with valuable insight and feedback.
> And others who do have such insight and experience don't
> necessarily agree with this community on every single issue.
It might ease the understanding of this community if you could tell
use who the other communities / personas are.