New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should models have direct access to views? #21

Closed
rlayte opened this Issue Oct 18, 2010 · 3 comments

Comments

Projects
None yet
2 participants
@rlayte

rlayte commented Oct 18, 2010

I'd like to see more separation between the application layers. From looking through the documentation it seems like models can directly access views and even insert content. The problem with this is that if you want to swap out view components you will also need to make changes to the model code. IMO models should know as little as possible about the rest of the system and changes should occur solely through events dispatched when data is changed.

P.S. I haven't had much chance to seriously investigate the framework so these thoughts are based on reading the documentation and my initial discoveries when creating a couple of extremely simple hello world apps. Very possible I'm just misunderstanding something...

@jashkenas

This comment has been minimized.

Show comment
Hide comment
@jashkenas

jashkenas Oct 18, 2010

Owner

It's entirely up to you, how much you'd like to have your model and view layers connected (or disconnected). Models have no reference to any specific view by default, although you can certainly pass them one should you choose to.

At one end of the extreme, you can have models and views separated entirely, with a controller creating a data object for the view to render from...

// Inside a controller.

var data = {
  title: model.get("title"),
  author: model.authorFullName()
};

view.render(data);

Or you can have a model reference a view, if it corresponds one-to-one with it.

var RowModel = BackBone.Model.extend({
  initialize: function() {
    this.view = new RowView({model: this});
  }
});

Backbone tries to provide a minimal set of ground-level functionality, while being as undogmatic as possible, with respect to how you structure your client-side code.

Owner

jashkenas commented Oct 18, 2010

It's entirely up to you, how much you'd like to have your model and view layers connected (or disconnected). Models have no reference to any specific view by default, although you can certainly pass them one should you choose to.

At one end of the extreme, you can have models and views separated entirely, with a controller creating a data object for the view to render from...

// Inside a controller.

var data = {
  title: model.get("title"),
  author: model.authorFullName()
};

view.render(data);

Or you can have a model reference a view, if it corresponds one-to-one with it.

var RowModel = BackBone.Model.extend({
  initialize: function() {
    this.view = new RowView({model: this});
  }
});

Backbone tries to provide a minimal set of ground-level functionality, while being as undogmatic as possible, with respect to how you structure your client-side code.

@rlayte

This comment has been minimized.

Show comment
Hide comment
@rlayte

rlayte Oct 18, 2010

I agree that frameworks shouldn't completely prescribe how you structure your code, but I think the whole point of them is to do that to some extent. What I like about application frameworks (instead of using a custom MVC implementation) is that they provide a common structure between applications allowing developers to quickly get up to speed on projects.

As you mention in another ticket, MVC is very vague and implementations vary wildly. However, the key concept of the 'pattern' is to decouple code and allow for a more modular approach to development. Creating concrete references to views inside the model layer makes this extremely difficult and IMO should be at least discouraged by the framework's architecture.

rlayte commented Oct 18, 2010

I agree that frameworks shouldn't completely prescribe how you structure your code, but I think the whole point of them is to do that to some extent. What I like about application frameworks (instead of using a custom MVC implementation) is that they provide a common structure between applications allowing developers to quickly get up to speed on projects.

As you mention in another ticket, MVC is very vague and implementations vary wildly. However, the key concept of the 'pattern' is to decouple code and allow for a more modular approach to development. Creating concrete references to views inside the model layer makes this extremely difficult and IMO should be at least discouraged by the framework's architecture.

@jashkenas

This comment has been minimized.

Show comment
Hide comment
@jashkenas

jashkenas Oct 18, 2010

Owner

I agree -- for me, the most frequent pattern is one-to-many between a model and its views, in most cases. Often a model will be rendered (or partially represented) in many different pieces of UI. The model knows nothing about this, but the views naturally contain references to the model that serves as their data source.

Is there any particular piece of the documentation that you'd like to see changed or clarified to make this point more clear?

Owner

jashkenas commented Oct 18, 2010

I agree -- for me, the most frequent pattern is one-to-many between a model and its views, in most cases. Often a model will be rendered (or partially represented) in many different pieces of UI. The model knows nothing about this, but the views naturally contain references to the model that serves as their data source.

Is there any particular piece of the documentation that you'd like to see changed or clarified to make this point more clear?

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment