Future ideas
Mark Nijhof
Chad and me have been talking about some changes that we (maybe more
me, anyway, I am a dreamer ;) would like to see happening. One of
these changes is that we might want to drop the controllers all
together and only have behavior chains. Because if you look at the
current controllers they don’t offer any added benefit (except for
conventional configuration). This also mean that you will not have
multiple action methods in one class anymore, so in that respect a
little bit less freedom, added benefit is that SRP is more enforced :)
An other thing that I really like is splitting up the web page into
multiple responsibilities and give each responsibility its own model
and behavior chain. What I mean with this is that the master page has
its own model. The actual view will have its own model, you will still
be playing with partial views that take their model from the model of
the view it self. But you will also be able to add partial views that
have their own model not related or attached to the model of the view
that calls the partial view.
The mean reason I really like this idea is that currently the model is
getting very fat, it needs to know about to many things (things
unrelated to each other). One downside might be if you need the same
information in the different models like logged on user, but that can
perhaps be solved using some sort of caching.
Url’s will most like not be auto discovered anymore, but this was a
big issue anyway and in most cases not even possible. So I don’t see
that as a big loss. Now I have an idea on this as well but it won’t be
sufficient.
This means that now you can have the following scenario:
/Home/Index
/Home/Index.aspx (view)
- HomeModel
- - - access_the_database_through_a_unit_of_work
- - get_last_five_blog_posts
- - execute_the_results
- - - - Shared/BlogPostPartial.ascx (takes posts from the HomeModel.Posts)
- - load_the_current_principal
/Shared/MasterPage.aspx
- MasterPageModel
- - set_the_current_site_details_on_the_output
/Shared/MenuPartial.ascx
- MenuModel
- - load_the_current_principal
/Shared/LastTenPublishedPostsPartial.ascx
- LastTenPostModel
- - get_recent_blog_posts
What happens here is a action invoker loads the view and the view has
a model defined which has a chain of behaviors attached to it. These
get executed. Also the view need a master page that has its own model
and chain of behaviors that get executed. During executing of the view
and master page the render (or something else) discovers that there
are partial views being loaded that depend on a model _not_ provided
by the parent model, then it will also get these models and behavior
chains.
Now this needs much thinking and finalizing but I hope you can
appreciate that doing it this way you increase reusability and you are
really separating the different concerns. The models will become a lot
cleaner.
Now I don’t know yet how to configure all of these things, you
probably want to be able to re-use models with different behaviors
attached going towards different views or partial views. Perhaps a
partial view should also be able to be rendered on its own with its
own Url. Some urls will only have Json results or RSS results and so
on.
Anyway this is something that I feel that could be awesome but feel
free to burn it to the ground :)
-Mark
Ryan Kelley
I like the sound of it overall. Controllers and ViewModels are becoming very fat in our app right now, especially controllers. A couple of things come to the top of my head, and I am sure I will think of more:
1. I think, we should find a way to make the Model (ViewModel or DisplayModel) reusable
2. Would a chain of behaviors be able to be broken, and then sent to another Action instead.
i.e. you have url: /blog/YEAR/MONTH/DAY/SLUG which brings back 1 article. But someone only gives you /blog/YEAR/MONTH and now you want to redirect over to an action that handles listing of blog posts.
3. How flexible do you think the use/reuse of partials going to be?
4. What about naming / organization conventions of your Web project? I don't want to end up with a bunch of crap in one folder :)
5. By no automapped Url's are we talking no figuring out of parameters? or every url has to be defined manually? I am really fine either way I think on this one.
6. Is this going to be a lot more "computing" being done inside the framework, as in performance and CPU cycles? (this seems odd, but if you are hosting in the cloud it is a realistic one as CPU cycles == more $$$$)
If we start to work on this, can we please make a Branch from the trunk? As always, I would really like to help with this, as I know I am one of the few using Fubu in production sites.
-Ryan
Mark Nijhof
2. I was thinking the chain that is initiated by the Url has the
ability to redirect and such. Other behavior chains are not the main
responsibility of the Url so should just not display or whatever. Your
example would most likely just be a different Url with a different
behavior chain, but using the same model and view.
3. Very flexible, I think the Render and RenderPartial functionality
should take care of the plumbing, the models and (partial) views
should not care if they are loaded as a main view or as a partial. Of
course a view has a master page and will behave weird if loaded as a
partial, but if you create a partial that returns a table it should be
able to load it via the RenderPartial or as its own url or when it has
its own model.
4. I completely left out that we have also been talking about the
ability to configure your conventions like Fluent NHibernate does
this, that means that you will get much more freedom in how you want
to structure your project and where FubuMVC gets its models, views and
behaviors from (and other stuff). I'll write up something about that
later today.
5. I think because of number 4 you could get all urls working without
parameters, but when you get complicated Urls it is probably not going
to work.
6.You would get a little bit more overhead, (I guess) the key here is
maintainability and SOC and all the other good principles. I am sure
that putting more stuff together and duplication of code (less reuse)
removing the IoC and such things will result in less CPU cycles :-) it
hasn't been my greatest concern, it should still be fast do. One thing
I was thinking about as well is when .Net 4.0 is released we have all
the nice parallel computing so perhaps some behavior chains can run in
parallel and in some chains even the behaviors can run in parallel?
Branching, nah ;-) perhaps we should make a 0.001a release and keep
that "stable" and continue on the trunk?
-Mark
Ryan Kelley
How would this work:
ArticleAddViewModel Add()
{
// Setup a new Article and return it on output ViewModel
}
ArticleAddViewModel Edit(ArticleSelectForEditViewModel inModel)
{
// Load article if id is correct and return it on the output viewmodel
}
ArticleAddViewModel Save(ArticleAddViewModel inModel)
{
// Check if the article is valid
// if it is save it and redirect to the view of the article
//
// if not add validation errors to outputViewmodel (Along with incoming data) and return output VIEWModel
}
Now all of these actions are set to use the same view page and partials.With the same ArticleAddViewModel - but different behaviors depending on Url.
Just a thought of mine.
RE: Branching: We should branch something, either current trunk or new trunk. Makes me no difference.
-Ryan
Mark Nijhof
- Url
- Behavior Chain (populated with default behaviors, but will always be
customized)
- View or Model (if a view is defined the model is found by processing the view.
Now we could see the last behavior as the controller now only having 1
responsibility and looks like any other behavior. But from there we
might be able to do something with conventions.
Anyway now you would have:
/Article/Home (url)
- ArticleHomeView using ArticleViewModel
- - UnitOfWork behavior
- - HomeArticle behavior
- - Reder the results behavior
/Article/Add (url)
- ArticleAddViewModel (no view)
- - UnitOfWork behavior
- - AddArticle behavior
- - RedirectToArticleHome behavior
/Article/Edit (url)
- ArticleAddViewModel (no view)
- - UnitOfWork behavior
- - EditArticle behavior
- - RedirectToArticleHome behavior
/Article/Save (url)
- ArticleAddViewModel (no view)
- - UnitOfWork behavior
- - SaveArticle behavior
- - RedirectToArticleHome behavior
I am not sure in your case what the difference between Save and Add is?
Does this make sense too you? And anybody else have something to add
-Mark
Ryan Kelley
-Ryan
Mark Nijhof
-Mark
John Howes
Mark Nijhof
(http://www.udidahan.com/2009/05/31/webcast-on-soa-in-the-e-van/) and
he is talking about what I mean as well. Only he does connect things
on the browser and goes a lot further then I did. But it is an
interesting talk which we could get some ideas from as well. The talk
is recorded so no need to jump on it now :)
-Mark
David Alpert
I think it's an interesting concept, to forgo controllers in favor of a
chain of smaller SRP classes; it reminds me of the Unix philosophy of many
small effective apps that can be piped together - each piece becomes very
stable and reusable. I look forward to see where this goes.
BTW, with my limited time/resources, this kind of evolution is the reason
that I have held back about my offer to explore T4 templates and tooling
support. I have very much enjoyed watching this framework evolve, and it
doesn't seem quite settled yet. Several given snapshots are
production-ready, and in use, but overall the "rails of .NET" convention is
still shaking out, yes?
Keep up the evolution!
-David
Chad Myers
BTW, with my limited time/resources, this kind of evolution is the reason
that I have held back about my offer to explore T4 templates and tooling
support.
Mark Nijhof
Mark Nijhof
these are (saw a few tweets about it), they are not just mine. Chad
and me have been talking about these. Credit where credit is due. I
just wanted to hear your feedback on them too.
-Mark
CraigCav
out dependencies for instantiating a controller for a particular
action - I had assumed that this was probably a smell of my controller
doing too much. Treating a controller action in the same way as the
behaviours seems like a decent step in keeping with SRP, so it will be
interesting to see how this plays out.
On May 30, 12:27 am, John Howes <john.ho...@gmail.com> wrote:
> I like what I see so far. I've been leaning more and more away from having
> traditional controllers since you guys have been discussing this. I always
> thought they were a pretty clear violation of SRP (which causes a lot of
> confusion, since people actually use controllers to teach SRP), and I've
> been annoyed at having to figure out which dependencies I actually need when
> instantiating a controller to perform a single action (kind of defeats the
> purpose of constructor-based dependency injection, right?). I know this is
> just general feedback on the approach, but I guess I'll have to react to the
> details as they emerge.
> John
>
>
>
> On Fri, May 29, 2009 at 5:55 PM, Mark Nijhof <mark.nij...@gmail.com> wrote:
>
> > Anyone else any comments? Good or bad?
>
> > -Mark
>
> > > That looks promising. In my case Add just sets up the empty form to get
> > > passed to the view, could set some defaults there though too.
>
> > > -Ryan
>
> > >> > Mark,
>
> > >> > How would this work:
>
> > >> > ArticleAddViewModel Add()
> > >> > {
> > >> > // Setup a new Article and return it on output ViewModel
> > >> > }
>
> > >> > ArticleAddViewModel Edit(ArticleSelectForEditViewModel inModel)
> > >> > {
> > >> > // Load article if id is correct and return it on the output
> > >> > viewmodel
> > >> > }
>
> > >> > ArticleAddViewModel Save(ArticleAddViewModel inModel)
> > >> > {
> > >> > // Check if the article is valid
> > >> > // if it is save it and redirect to the view of the article
> > >> > //
> > >> > // if not add validation errors to outputViewmodel (Along with
> > >> > incoming
> > >> > data) and return output VIEWModel
> > >> > }
>
> > >> > Now all of these actions are set to use the same view page and
> > >> > partials.With
> > >> > the same ArticleAddViewModel - but different behaviors depending on
> > Url.
>
> > >> > Just a thought of mine.
>
> > >> > RE: Branching: We should branch something, either current trunk or new
> > >> > trunk. Makes me no difference.
>
> > >> > -Ryan
>
>
> read more »- Hide quoted text -
>
> - Show quoted text -