This is not a specific code-based question. I'm looking for some intuition here with respect to view-model binding in backbone.
Imagine I have a simple person model with properties id, First and Last name. Then I have a collection of said models returned from a JSON web service. I understand how to retrieve and update a given item via sync using backbone. Where I feel sloppy is in my binding of views and models -- this is where I need a good explanation and some help on best practices.
When I create my view for a list of people, I show each person in a div with the class of the div containing TWO classnames: one named "personclass" and the other with the id of that person. Registering click event for "personclass" lets me grab the 'other' class - which is the id - then use that in a hash to manipulate the specific person (the underlying model of that person).
My manual view-model binding by referencing class names feels incredibly sloppy and I sense that I'm missing something fundamental about backbone. Quality of examples out there vary, so I will be grateful for a clean and easy explanation here.
There's nothing necessarily wrong with this approach. It can be quite beneficial when you have a memory constrained environment, for example.
Another approach, though, is to render a new Backbone.View for each item in your collection. Then each view instance can be specifically focused on the one item that it is displaying. You won't have to worry about adding the model's id to the rendered HTML, either.
I wrote an article a while back that explains both of these scenarios, shows how to accomplish each, and gives pros and cons of them:
http://lostechies.com/derickbailey/2011/10/11/backbone-js-getting-the-model-for-a-clicked-element/
Related
We are making a quiz application, I'm trying to integrate my Angular 2 UI with the REST api.
Our Quiz domain model consist of the following (simplified) hierarchy:
Quiz
Category
Question
Choice
where parent doesn't know it's children, but child knows it's parent. For example, Choice has a reference for a Question, but Question doesn't have reference to choice. We chose this approach to be able to fetch the quiz data more flexible and modular approach, also avoiding circular references.
However, in front end it's counter-intuitive to use inverted linking, as views are built naturally layer-by-layer iterating deeper in the domain object structure. It makes sense to render view for Question first, and render sub-view for Choices after. It just seems impossible with the current domain model, where I should start from Choice.
My question is, if it's common or approved to convert the domain model on the front end, so I wold gather all data and add Choice reference to Question afterwards, making the model compatible for top-down approach? And of course convert it back when POSTing to REST api.
Does this indicate bad design, or is it approved to alter the domain model?
It's not "convert domain model on front-end" because your front-end is not playing with domain model. It's playing with Data Transfer Object (json object returned from calling server API in this case). So feel free to do everything you want with DTO on client.
I'm currently rebuilding a client's small mobile page, on my own dime, as a way to learn MVC and AngularJS, and in preparation for a much larger project for another client. The page I'm learning on is a single-page online ordering app for a pita restaurant. It allows you to choose from a list of pitas, then a second View allows you to customize your pita with various vegetables, cheeses, sauces, etc., followed by a third View, a form which allows you to submit your order.
My question is about the Model. I've built a system which takes the output from the database of menu items (pitas and toppings) and generates a JSON file, the Model, for Angular to parse and display for the user, but I'm curious where the user's selections will be stored.
Do I create another Model specifically for the user's selections or do I modify the original Model to hold the user's selections in addition to the original data?
This is somewhat complicated question in the sense that there are many variables. I am just going to layout how I would approach the decision:
Modifying the existing model being passed to the client means a few things.
First, it means that I won't have another model to deal with, but that the model is not focused on one thing (SRP violation). It is specifying a model in my domain as well as the relationship it has to another thing, the order. This leads to the object being in odd states in the sense it represents different things at different times/situations.
Second, I will have do do this to all my models that maybe connected to an order. Multiplying the above problem.
Creating a new model to represent an order mean another model to deal with (creating an API/service to manage it as well). The plus side is that I will be able to keep it focused on one thing: tracking an order. This means that my other models don't have to change and I know what the object truly represents at all times.
I obviously lean toward creating a new model because it is extendable/flexible and more clear to understand/support.
This doesn't have much to do with Ng or MVC or JSON. It has more to do with creating your models to most accurately and clearly represent your domain.
There maybe other consideration as well given specifics. Let me know by commenting.
This is more of a theoretical question rather than language specific, but I'm mostly referring to AS3.
Let's say I have an app that shows buttons through a couple of levels of navigation.
For example artistsAlphabetical->albums->songs or songsAlphabetical->song or albumsAlphabetical->album->song
so we'd set up a model(Data) with all the songs (the lowest common denominator - it would have the artist/album/year etc. info within the song object)
Let's say we don't have a dataset for the albums and need to extract that from songs. or we do have a datasaet and need to match them up.
Where should that fall under? Model or Controller?
I can find reasons for either, but am wondering what the "correcter" way would be.
Next we have the View with all the buttons to do the sorting.
When you click on the sort button Artists-A - that's the View sending a message to the Controller to do something (get alphabetical list of artists that start with A). The end result should be a new (paginated view if necessary) with buttons for each artist.
Which part of MVC should be responsible for each step?
Generating a list of artists that start with A
would it be the controller that says - 'Hey model - Artists that start with 'A' NOW!'
or, would it be more like 'Model - send me a list of all the Artists, I need to find the A-dawgs'?
essentially should the model do the sorting (and cache it if possible/needed) or should the logic be under the Controller, and the Model can store the cache?
So once we have a list of the artists, we need to create a button for all the ones that fit on the screen plus some previous/next buttons. Who should be creating the Buttons?
Should there be a View Controller? A Sub-Controller that only deals with the logic needed to create the views? Or would the logic be part of the View? It seems to me that the app's Controller would be all like 'not in my job description... I gave you the list you needed rest is up to you'
I feel like I'm conflicted between two views of MVC, one (mvC) - where the Controller is working like a motherlicker, and the Model is a glorified data holder and the view manages DisplayObjects. Or (an MVc) where the controller is the manager/delegator that makes sure that the Model and the View communicate properly, so that the model and view would have a fair amount of logic, and the controller would handle communication and delegate top level interaction.
While I am doing most of my stuff in AS3, I am curious how other languages would handle this. For example, in PHP Frameworks, you wouldn't need to worry about the button logic and event handling as much as with as3, where you need to watch Garbage collection, so the workload of one component there might be different than in a Cinder++, processing or actionscript app.
I don't know AS3. I do both Spring MVC/Java, which really lets you do either approach, and also Ruby on Rails, which favors smart models and dumb controllers. I like the smart model/dumb controller approach better.
So to me, anything to do with sorting and filtering the data should absolutely be done in the model, as should the process of extracting Albums from a list of Songs.
In Rails, I would put the process of creating the set of buttons in the view layer without question. If there's actual logic involved, that would go into a view helper method.
As you stated already, this comes down mostly to preference, but typically I would opt for the sorting to be done in the controller. I tend to keep my models purely about data storage and reduce the amount of functionality in them. So in your example, the model's job would be to hold all of the artists' data, and the controller's job would be to extract the artists starting with "A" from that data, and subsequently passing that sorted data to the view.
I don't use traditional MVC anymore, so I tend to think more in terms of PureMVC (proxies, mediators, and commands) now.
In general, I tend towards more functional proxies (think model) where the data gets abstracted (for the typical reasons for abstracting data). So, in your cases, there would be a MusicLibrary proxy, and would probably have methods like byArtist(), byTitle(), byRandom(), etc.
In a PureMVC app, a sequence for your scenario would look like:
Component catches mouse click and sends Mouse.CLICK
Mediator wrangling the component catches event, and sends notification SORTBY_ARTIST_CLICKED
Command which is requesting notification of SORTBY_ARTIST_CLICKED, calls the the byArtist() method on the proxy, builds a notification NEW_MUSIC_LIST w/ the data and sends it
Mediator requesting notification of NEW_MUSIC_LIST then does its thing and updates the components is is wrangling
I think this would align with what JacobM describes as smart model / dumb controller. I think that this approach leads better resuse, and also better isolates impact from chages.
I will say that in general, if I have different views of the same data (like in your case), I will use commands to push out the data, but if a view just gets a data update I will often have the view just pull the data from a proxy.
I want to give my previous question a second chance since I think I have chosen a bad example.
The question is how I should deal with situations where an object still can change after I have used it to do something and the new state is relevant for what is being done.
Example in pseudo-code:
class Book
method 'addChapter': adds a chapter
class Person
method 'readBook': read an object of class Book
Now when I ask the person the read a book, at least in PHP where the object will be passed by reference, the book object can still change. I could insert a chapter between chapter 3 and 4 while the person is already reading chapter 6. How can I deal with these kind of situations?
Maybe notifying the person that the book has changed? You can do it with events (not sure how events work in PHP). Another way is to implement the Observer/Observable pattern.
Any of the above answers is good for a good solution depending on your business demand.
You asked "How should I deal with situations..." it depends:
Is adding a chapter after you already shipped a book to the user legal? if not- you should throw an exception (I do not know if PHP supports exceptions, but anyway- you should treat is as an error situation).
Another solution would be to make sure that you expose and object that is already whole and does not expect changes to be made to it- this may be a valid solution especially if your decision to enable this kind of 'streaming' is performance oriented but you don't have real evidence that that this section is a performance bottleneck.
Now lets sat the addition of a new chapter is legal.
Do you want the change to be known to existing client or only to new clients?
If the former- you should implement some kind of notification logic (one of the suggeted forms is the a publisher/subscriber pattern, but there are others).
If the letter- you should make your book object immutable, so mutating operations will not be seen in existing clients, rather they would create an entirely new book the would be passed to new clients (Persons).
I could go on and on, But I suggest that next time you elaborate more on the exact problem you are trying to solve, since as you can see- the same problem can have a different solution in different domains.
Seems to me you are attempting to perform concurrent tasks. You might want to consider serializing activities to your objects instead, certainly in the case of PHP.
It seems that the decision to make your objects fully cognizant of their roles within the system, and still avoid having too many dependencies within the domain model on the database, and service layers?
For example: Say that I've got an entity with a revision history, and several "lookup tables" that the data references, your entity object should have methods to get the details from some of the lookup tables, whether by providing access to the lookup table rows, or by delegating methods down to them, but in order to do so it depends on the database layer to read the data from those rows. Also, when the entity is saved, It needs to know not only how to save itself, but also to save entries into the revision history. Is it necessary to pass references to dozens of different data layer objects and service objects to the model object? This seems like it makes the logic far more complex to understand than just passing back and forth thin models to service layer objects, but I've heard many "wise men" recommending this sort of structure.
Really really good question. I have spent quite a bit of time thinking about such topics.
You demonstrate great insight by noting the tension between an expressive domain model and separation of concerns. This is much like the tension in the question I asked about Tell Don't Ask and Single Responsibility Principle.
Here is my view on the topic.
A domain model is anemic because it contains no domain logic. Other objects get and set data using an anemic domain object. What you describe doesn't sound like domain logic to me. It might be, but generally, look-up tables and other technical language is most likely terms that mean something to us but not necessarily anything to the customers. If this is incorrect, please clarify.
Anyway, the construction and persistence of domain objects shouldn't be contained in the domain objects themselves because that isn't domain logic.
So to answer the question, no, you shouldn't inject a whole bunch of non-domain objects/concepts like lookup tables and other infrastructure details. This is a leak of one concern into another. The Factory and Repository patterns from Domain-Driven Design are best suited to keep these concerns apart from the domain model itself.
But note that if you don't have any domain logic, then you will end up with anemic domain objects, i.e. bags of brainless getters and setters, which is how some shops claim to do SOA / service layers.
So how do you get the best of both worlds? How do you focus your domain objects only domain logic, while keeping UI, construction, persistence, etc. out of the way? I recommend you use a technique like Double Dispatch, or some form of restricted method access.
Here's an example of Double Dispatch. Say you have this line of code:
entity.saveIn(repository);
In your question, saveIn() would have all sorts of knowledge about the data layer. Using Double Dispatch, saveIn() does this:
repository.saveEntity(this.foo, this.bar, this.baz);
And the saveEntity() method of the repository has all of the knowledge of how to save in the data layer, as it should.
In addition to this setup, you could have:
repository.save(entity);
which just calls
entity.saveIn(this);
I re-read this and I notice that the entity is still thin because it is simply dispatching its persistence to the repository. But in this case, the entity is supposed to be thin because you didn't describe any other domain logic. In this situation, you could say "screw Double Dispatch, give me accessors."
And yeah, you could, but IMO it exposes too much of how your entity is implemented, and those accessors are distractions from domain logic. I think the only class that should have gets and sets is a class whose name ends in "Accessor".
I'll wrap this up soon. Personally, I don't write my entities with saveIn() methods, because I think even just having a saveIn() method tends to litter the domain object with distractions. I use either the friend class pattern, package-private access, or possibly the Builder pattern.
OK, I'm done. As I said, I've obsessed on this topic quite a bit.
"thin models to service layer objects" is what you do when you really want to write the service layer.
ORM is what you do when you don't want to write the service layer.
When you work with an ORM, you are still aware of the fact that navigation may involve a query, but you don't dwell on it.
Lookup tables can be a relational crutch that gets used when there isn't a very complete object model. Instead of things referencing things, you have codes, which must be looked up. In many cases, the codes devolve to little more than a static pool of strings with database keys. And the relevant methods wind up in odd places in the software.
However, if there is a more complete object model, we have first-class things instead of these degenerate lookup values.
For example, I've got some business transactions which have one of n different "rate plans" -- a kind of pricing model. Right now, the legacy relational database has the rate plan as a lookup table with a code, some pricing numbers, and (sometimes) a description.
[Everyone knows the codes -- the codes are sacred. No one is sure what the proper descriptions should be. But they know the codes.]
But really, a "rate plan" is an object that is associated with a contract; the rate plan has the method that computes the final price. When an app asks the contract for a price, the contract delegates some of the pricing work to the associated rate plan object.
There may have been some database query going on to lookup the rate plan when producing a contract price, but that's incidental to the delegation of responsibility between the two classes.
I aggree with DeadBeef - therein lies the tension. I don't really see though how a domain model is 'anemic' simply because it doesn't save itself.
There has to be much more to it. ie. It's anemic because the service is doing all the business rules and not the domain entity.
Service(IRepository) injected
Save(){
DomainEntity.DoSomething();
Repository.Save(DomainEntity);
}
'Do Something' is the business logic of the domain entity.
**This would be anemic**:
Service(IRepository) injected
Save(){
if(DomainEntity.IsSomething)
DomainEntity.SetItProperty();
Repository.Save(DomainEntity);
}
See the inherit difference ? I do :)
Try the "repository pattern" and "Domain driven design". DDD suggests to define certain entities as Aggregate-roots of other objects. Each Aggregate is encapsulated. The entities are "persistence ignorant". All the persistence-related code is put in a repository object which manages Data-access for the entity. This way you don't have to mix persistence-related code with your business logic. If you are interested in DDD, check out eric evans book.