I'm working on a Durandal SPA, and I've setup some views and viewmodels. However, I thought the MVVM architecture would also involve a "model" segment (Model, View, ViewModel--right?).
However, the Durandal Getting Started page says this under the "Organization" section:
If you expand the App folder, you will find the source for the entire
SPA sample. Here's the high level organization you will find:
App
durandal/
viewmodels/
views/
main.js
Absent from this structure is a "models" folder. Where are you supposed to put your models in a Durandal app?
I've looked at some other sample apps, and I can't find a "models" folder (or anywhere that models are residing) for any of the sample apps I've reviewed.
The "models" folder (which isn't there) seems to me to be a critical part of a Durandal app. However, it's not there--and therefore, I am questioning my understanding of how Durandal (and MVVM apps) are designed. There is surely something I am not understanding... can someone fill me in on the intended structure of a Durandal app, and where to put your model objects?
The answer is that Durandal only gives you the structure necessary to run, and nothing more. It uses a viewmodels and views folder, so it tells you to make one. Durandal doesn't use a models folder, you do.
I make one in my projects. If you feel like it fits your dev style, you can and should make one yourself.
Notice that it also leaves no place for code that is not a viewmodel, which surely will exists in any application. I highly recommend making a modules folder for this purpose.
Don't think that the only things you can or should do are the ones you see done in the Durandal tutorials. You are the developer. You will have to build on top of what Durandal provides, and this means making your own choices.
In my applications, the models have always been defined by the REST services or WebAPIs that the app makes requests against. I haven't had a need to define those models in the application code. The models are defined by the server/service side.
When using something like Breeze, the model is just a JSON representation of your entity models in your database.
If you feel more comfortable defining those models in your application code, you are more than welcome to. If I did something like that, I would put it in a App\models folder as you suggested. I don't think you will need to do this most of the time, though.
Related
I'm just getting started with Go and as a first project I decided to make a simple REST API server. Unfortunately, I've hit a problem as I can't seem to find the best way to structure my project.
So far, I'm using the same structure as a Rails project meaning having controllers and models in their own folders, but it doesn't as idiomatic as go code should be.
Does anyone have any advice on how to properly structure a project?
It's probably do-able, but because of static compilation you're going to have a bit of a mess if you want a lot of Rails' automagic for figuring out routes.
I'd probably just have a models package with all the database models, and then something based on Gorilla's mux to bind some routes to some actions.
If things are getting complicated you can try a larger framework like Revel, which might be more suitable for a larger MVC application.
I am currently working on a Kendo Mobile project using the MVVM pattern but having difficulty on how I should separate the following Kendo components:
Schema Model
Data Source
ViewModel
View
I am using RequireJS to help with modularizing my JavaScript, and would like to keep things as uncoupled as I can. I don't really know where to put the data sources in my project. Is the following folder structure appropriate? I am using web service calls exclusively for handling my data:
app/
model/ (all the schema models js)
dataSource/ (all the data sources with CRUD service calls js)
viewModel/ (holds all the view models js)
view/ (holds the init, beforeShow, show, afterShow functions of respective views js)
library/ (public libraries like jquery, requirejs)
common/ (utilities)
I am unsure about the folder names and such, as some articles I've read had said the model includes the data source. I don't think that's right, but I am fairly new at the MVVM pattern. Any help and recommendations of the appropriate folder structure would help a lot! As a side note, I feel that the view and viewModel folders should be combined but I am not sure...
Well I'd like to say: "It depends." ;o)
IMHO, it depends a bit on your plans in the future. Usually, I would put the DataSource into the Model part because the Model is the result, which is returned by the DataSource but also the entities, which are passed to the DataSource in case of writing operations. So if you're not planning to replace your data retrievel implementation its absolutely fine to put it in there.
If you're not sure or you have already plans, I would recomment do put the Interfaces in the model folders, since they are still related and put the data retrieval implementation somewhere else. I think, this is usual common approach.
Hope it helps to decide.
Lately I seem to be struggling to organize all of the different Classes/Objects I am working with. In my case, I work for a company that has 3 core products that are different - but share some core functionality. So, they will also share classes. To muddy the waters some more, I am writing ASP.NET MVC app - which has an implicit location for Classes (the Model folder).
So - here is how we are currently doing things. I am going to refer to the product as NewProduct. xxx is the company name:
xxx.Core - Classes used in all products. These could be helper functions, actual classes with logic, etc.
xxx.NewProduct.Web - The MVC Web App for the NewProduct. The Models folder is empty.
xxx.NewProduct.WindowsService - A Windows service - part of the NewProduct.
xxx.NewProduct.Models - Basically, this replaces the Models folder in the MVC Web app. They are in their own project so that the DomainLogic can fill them and pass them back to the MVC App.
xxx.NewProduct.Objects - Classes with logic (not just Skeletons like Models) that are shared between Web and WindowsService.
xxx.NewProduct.DataAccess - This is the DAL, not all that important to my question here.
xxx.NewProduct.DomainLogic - This is the business logic layer (makes calls into DAL).
Also, if we are to write some other app in the future (Mobile, Desktop, etc) these can be reused by it as well.
My main problem is when I am trying to decide where to put an object, there are times where I am not sure where to put it. Is this normal? Do others have this problem? Any suggestions?
of course it's normal! there is no one right way to divide your modules. but don't spend too much time on this. we are living in IDEs age - you can always refactor. for me, the most important is readability. when other programmers from your team look for the some class/functionality they should not be surprised - that's all. for example i have no idea what can i find in module named Objects (but i don't know .net nor specific of your application).
I have several classes that exist persistently throughout application lifetime and can contain any code a programmer might need to run (stuff like for example that is executed when a user resizes the app window). These classes are basically empty templates and aren't for a single task (uh oh, sounds like bad OOP, but please stay with me here). There are several of these classes in my framework and which one is integrated into the rest of the framework depends on the build target (web, desktop, mobile, etc). Currently these classes are named:
AppModule
AppDesktopModule
AppAndroidModule
etc.
But I'm not happy with this naming. I'd like to give them a name that somehow clarifies that these classes are persistent throughout app lifetime. Does anyone have ideas for a better naming?
In a MVC application, what are some of the components that make up the application. What tools and functionality is missing that you would like to have. Regardless of the server-side language, what would you want?
I see a lot in my code where I code some much functionality that it seems should already be there. I looked at Google web toolkit and they seem to get it right. Widgets are widgets and you simply add them to your application.
For example. I work with J2EE apps but in other languages, the components are the same.
Controller Objects
Controller handlers, defined by methods in the controller objects.
Configuration files defining the URL mapping and settings.
Template server page files (e.g. JSP/ASP files).
Configuration files defining O/RM mapping between application objects and the database.
Configuration files defining the database connection properties.
JavaScript libraries (e.g. jQuery)
Logging configuration files
Resource message bundle files
Validation configuration files or code
Middleware components and objects (EJB configurations, JMS/Messaging configurations, etc).
Credit Card or other middleware connectivity APIs and libraries.
Anything else you can think of?
Built-in Unit Testing Component
I think one thing you're missing from that very exhaustive list is the automatic binding of request properties to form objects, and the saving of these objects to the session where appropriate. Form objects here being the object on the server that represents the current state of the HTML-based for displayed to the user.
I think scaffolding and automatic admin interfaces are very nice features too, that I dont want to miss ;)
You've made the assumption that all MVC applications are websites. MVC is widely used for more than just web apps so things like URL mappers, template server pages and "Server side" languages are not associated with the MVC pattern, so much as a particular implementation and adaptation of the MVC for use in web apps.