Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I was reading someone's code where I came across Knockout and MVVM. I did some reading on both topics, but I'm still confused as to what problems they really solve, most likely because I just haven't built applications large enough to come across the problems that this framework/architecture solves.
I spent some time to understand this sample code -- http://knockoutjs.com/img/homepage-example.png -- from the Knockout home page. I was hoping if someone could explain to me what the same code would look like if Knockout were not used, and how that could be problematic.
(SO may not be the right platform for this question, so please let me know if there's some other Exchange that's more appropriate).
Thanks!
From 10,000 Feet
Knockout provides two-way data-binding between a view written in HTML and corresponding properties and functions on a viewmodel written in JavaScript.
Imagine you have an HTML view called contacts.html and a JavaScript viewmodel called contacts.js. Those two together would make a module, and Knockout would be the glue that binds them together.
MVVM stands for Model View ViewModel. I addressed the latter two above. The model is simply a JavaScript representation of a particular corner of your world, say, in this case, a Contact.
So, bringing together the above, we might have (in terms of directory structure):
models\contact.js
views\contact.html
viewmodels\contact.js
You might instantiate your model inside your viewmodel, and then bind your view to the viewmodel using Knockout.
MVVM simply provides for a great way to separate concerns and maximize reuse. As an example of reuse, you could bind your contacts view to many different contact viewmodels, depending on context. The context could be the size of the client device, a user's authorization profile, a "community" versus a "premium" version of your application, and so on.
Modifying by improvement any of the components of MVVM can be done in relative isolation without adversely affecting the application as whole. Hence the value of separating concerns.
Does that make sense?
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
why should we use modeling?
I currently write classes in my projects without having a model.
I think about the tasks of each class and write methods.
Now I want to know what makes modeling better? !
And how to use it? !
I'm familiar with UML design
Thanks .
Modeling classes has the following benefits:
Modeling allows you to design faster a complex software structure that requires the involvement of several classes:
On the model, you draw a couple of classes and links between them (associations, dependencies, etc...). You can then verify the consequences and fine tune the model.
While you could easily create a code skeleton to show several classes and perhaps some inheritance, it's more difficult to represent associations in code: is it a composition ? an aggregation ? a one to many ? or a many-to-many ? Each of this alternative would require some choices about how to implement the link, and this takes much more time. ANd once these choices are made and and the draft code will be done, you'll be less encline to change it.
Modeling allows a more compact overview over a complex class structure:
You can easily show 20 classes (without details) on a sheet of paper, and grasp how the parts are connected together.
With an IDE you can perhaps show 20 classes on a screen by folding the classes, but if you need to see the relation between the classes (so some details about class members, you dramatically decrease what you can show (and grasp) at once.
Modeling allows interactive discussions with people of diverse backgrounds, and not necessarily coding gurus. While business users won't grasp the subtle details of a model, they can grasp the relations and so participate constructively to the discussions.
Modeling provides a useful documentation for people who will join the project or will have to maintain it.
Modelling is not a substitute for programming
I wouldn't like to start a heated dogmatic debate. But I think that modeling should not replace programming:
If you start to put all the details on all the members of all the classes in your model, and then start to express complex constraints in OCL, you loose could loose your time, except if you work on mission critical systems in highly regulated environments.
The model will quickly be out of sync with the code, because in most of the case, only few projects have so much resources that they could afford double maintenance.
If you have some advanced tooling (e.g. Rational Rose for OOP or S-Designer for database models) that can do modeling, code generation, reverse engineering to update model and so on, then it can make sense to put much more effort in the model.
If not, design the outline of your system in a model without too much details (e.g.put members important for the understanding of the overall structure and responsibilities), and keep the additional effort for the coding.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have made use of a delegates in the past to share information about an Object (with it's associated properties) across different classes, but I'm planning a new App and thinking of using a Singleton Class to do this.
Is it mandatory protocol to use delegates to share information between classes, or can I simply employ a Singleton Class ?
Looking forward to some views or good advise on the topic.
You may be missing the basic point of Model-View-Controller, which is the primary pattern of Cocoa apps. Under MVC, there is no reason to "share information across…Tableview Controllers." There is a model layer. The model layer hold all the data. The view layer (including tableviews) reads the model layer and displays it. Views objects don't need to talk to each other very much. They mostly update the model and then read from the model.
You can implement the model as a singleton, or as an object that is passed into the view controllers when they are initialized. Both approaches have advantages. But there's no need for your view controllers to talk to each other in any case.
There are a lot of ways to share information between controllers. It solely depends upon your design what you opt to choose. Usually singletons are used to store information globally to be used by whole app anywhere. For example, to store game's score and its another stuff. Delegate is used to communicate between limited number of controllers. BTW you can broadcast your data to all "listening" controllers via Notifications. So again it really depends upon your design that what should you choose.
You do have several options. Core data, singleton, some sort of shared memory (maybe your pointer is in the Navigation Controller so you can share it with multiple screens -- or maybe in your AppDelegate), delegates, etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Just wondering how to start a project from concept,specs,dev etc. In development do you start with database design? or maybe theres a resource you know i can look at.
Starting with database design is actually a big pet peeve of mine. Sure, it's fine for some projects. Simple forms-over-data apps, stuff like that. But for anything more complex, anything that has a "domain" of logic, do not start with database design. Start with domain modeling. If you're taking business logic and putting it in code, then it's highly likely that the business users who define the logic flow do not think in terms of SQL or relational data at rest. They think in terms of logical interactions of concrete and abstract concepts.
As Eric S. Raymond said, "Smart data structures and dumb code works better than the other way around." Usually, when one starts with the database design, one creates a flat "dumb" data structure. Not dumb in the sense that it's a bad design, but in the sense that it has no built-in logic. It's flat and dimensionless. All of the intelligence would need to go into the code that uses it.
A rich domain model, on the other hand, incorporates business logic and concepts directly into the data structures. It's enhances the data itself with actual business intelligence, carrying that intelligence throughout the domain.
Now, this doesn't mean that you shouldn't think of persistence at all while designing the domain. But the persistence should be built to accompany the domain, not the other way around. Nilsson suggests starting with the domain and during the development of it take breaks to think and work on the persistence. This is because the domain model is really the core, but you'll need to evaluate any compromises on persistence to keep yourself realistic. Going for true persistence ignorance could dig yourself into some holes.
That all depends on what sparked the motivation to start a project in the first place. It could vary from sitting down and fleshing out detains of something that's been brewing amorphously in your mind for years, or sitting down and making a quick and dirty prototype to convince yourself that the genius idea you had that seemed so simple is actually quite a thorny bush that requires you to sit down and flesh out.
I never start with database design, as that's an implementation detail. I might not even want to use a database. I start with the functional design. What do I want it to do? Why? How? How does it do it differently from other approaches? Is the benefit enough to even bother doing it at all? You get the idea. Implementation design is tackled once I know clearly what I am doing and most importantly why.
That is very general but the first step is always to figure out and document what you want the application to do. Then I usually develop and ERD which defines the tables required to accomplish those functions along with the class structure that sits in front of those tables. Once those two big parts get done, it's usually pretty smooth sailing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm giving a presentation on using MVVM in real world applications and I'm including a section on the religious wars design decisions involved when using MVVM as a pattern in your application. In an MVVM application there are two main ways (that I know of) to instantiate a new View/ViewModel pair:
View-First in which you create a view and it creates its own ViewModel and sets it to its DataContext.
ViewModel-First in which you create new view models and create new views in response to changes in ViewModel properties, usually with ItemsControls and/or DataTemplates.
In your experience what are the pros and cons of each method? What do they enable and what problems do you run into with each?
Result Summary
View First - Pros
Easy to track which ViewModel is used by a View
View First - Cons
Doesn't allow a single View to be easily used with multiple ViewModels
Requires extra events to handle communication between Views and ViewModels
ViewModel First - Pros
Allows more complete testing of logic to open new Views and ViewModels
Tends to be DRYer as applications get larger
View and ViewModel are more independent and can be worked on separately more easily
ViewModel First - Cons
More difficult to set up in Silverlight without DataTemplateSelector and typed DataTemplates.
Given the Data Templating feature in WPF, I feel ViewModel-First is the way WPF was intended to be used.
I'll clarify that statement: Data Templating allows you to never instantiate views from your ViewModel. If done correctly, your Views and ViewModels could be kept in seperate projects that DO NOT reference each other. Furthermore, the ViewModel project should not even reference any PresentationFramework assemblies, making your ViewModels consumable by any conceivable user.
I tend to prefer the View-Model first simply because I feel it follows the DRY rule best. When you start creating larger scale applications I find this makes testing easier as well, thus outweighing the initial bit of headache you need to deal with when setting up the application.
Caveat - I use WPF not Silverlight.
By the VM instantiating the V (which is the way I do it) the view is independent and can be used independently of the VM (e.g. in a designer)
Personally, I am veering toward a MVVMC (model, View, ViewModel, Controller) where I have a controlling class which instantiates ViewModels and Views and 'joins them'. The C also then handles getting data (and caching it, etc.) and any communicating across VM and Vs (e.g if a V is instantiated, routes a command to its VM to perform some action, the VM will probably ask the C to perform the action on its behalf; the C can then raise appropriate events which other VMs can handle
If (whether using a controller or not) I need a VM to talk to another VM, it is harder to do so if the V instantiates a VM - because no I have to expose the VM in the V (or at least make some interface available so the 2nd VM can talk to the 1st).
I prefer to use view model first approach. For many reasons:
Vms are your application containing most of logic apart from glue code in form of behaviors or triggers.
If you creates views then you are responsible for its life and cleanup code. You have to deal with threading and other issues which are difficult to test. On the other hand of you create vms and leave the view creation logic with WPF via data template.. you don't have to worry about threading issue. And there will be better separation of concerns.
With vm first approach zero code behind.
With a project level isolation for view and vms you can restrict developers using view specific things like dispatcher in the view model leaving more cleaner and testable code base. I.e view project sprojec to vm. And vm project should not refer to any presentation lib.
If there is clear boundary between view and vm. Both can evolve and will be less fragile.
We've used ViewModel first, but when came in outsourcing, and using of blend became the most important thing, my boss said that View-first is better than Viewmodel-first - I disagreed with him (but one to many is not best ratio of votes ;-) ), because now we have some weirdo connections with events of view in code behind. Now I'm in point of no return and I`ve got stuck in some custom controls - because of the change.
I use a View-first (sort-of) approach. I define the View in collaboration with my client with a dummy viewmodel with test data. When we are satisfied, I proceed to extract an interface from the 'dummy' and implement the real ViewModel. I've found this approach most appealing for the following reasons:
It's fast as prototyping is in-expensive time-wise and I often get it right (ish) in the fourth or fifth try.
ViewModels tend to be easy (easier) to implement when I have an interface to adhere to.
I work in WPF, but I'd think it wouldn't be too different in SL. Also, I never spend time on testing views which may attribute to my choice of approach.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am just starting to play with Django/Python and am trying to shift into the MTV mode of programming that Django asks for (insists on). Deciding on what functions should be methods of a model vs simple being a function in a view has so far been confusing. Does anyone know of a book, website, blog, slideshow, whatever that discusses Web Framework programming in more general, abstract terms? I imagine just a book on object oriented programming would do it, but I feel like that would be overkill - I was looking for something web framework specific.
My basic rule in Django is: if you could conceivably need the functionality from somewhere other than the view itself, it doesn't belong in the view function.
I'd also recommend downloading some of the plethora of apps on Django Pluggables and seeing how they do it.
Once you do find some good guide, here's something to remember: Django is a bit special with its terminology. It uses "MTV" for Model, Template and View (and can mention also a URL Dispatcher somewhere along the way), whereas a more standard set of terms is "MVC" for Model, View and Controller.
Model is the same in both meanings - a model of a data entity, often linked to a database table, if the framework implements Object/Relational Mapping (which Django does).
But the two remaining terms might be confusing; where Django talks about Views, the 'rest of the world' talks about Controllers. The basic idea is that this is where the presentation logic is done. Calculations are calculated, arrays are sorted, data is retrieved, etc. I'd say that Django's URL dispatcher is also a part of the conventional Controller concept.
Django's Templates are comparable to Views elsewhere - here you have your presentation, nothing else. Where Django forces you to a very small set of logical commands, other frameworks often just recommend you not to do anything than present HTML, with some presentation logical elements (like loops, branches, etc), but don't stop you from doing other stuff.
So, to recap:
Model: Data objects
Controller (View in Django): Data process
View (Template in Django): Presentation
Oh, btw: For a Django-specific guide, consider reading The Django Book
I've not really used Django in anger before, but in Rails and CakePHP (and by extension, any MVC web-framework) the Fat Model, Skinny Controller approach to organising your methods has been a real eye-opener for me.
If you aren't absolutely set on diving into Django and don't mind trying something else as a start, you might want to give WSGI a shot, which allows you to template your application your own way using a third party engine, rather than having to go exactly by Django's rules. This also allows you to peek at a lower level of handling requests, so you get a bit better understanding of what Django is doing under the hood.
Here are a few links that might be helpful as an overview.
From my own experience, when I first started using MVC based web-frameworks the biggest issue I had was with the Models. Prying SQL out of my fingers and making me use Objects just felt strange. Once I started thinking of my data as Objects instead of SELECT statements it started getting easier.
MVC In laymen's terms
MVC: The Most Vexing Conundrum
How to use Model-View-Controller
View function should only contain display helpers or display logic. View functions should never access the model itself, but should take parameters of model data. It is important to separate the model from the view. So if the function handles accessing the database or database objects, it belongs in the model. If the function handles formatting display, it belongs in the view.