Naming convention of database models and view models - mobile

I have problem with my mobile application (I use Mvvm) - naming convention between models that I use for database (so classes with properties) and some part of abstract models that I use for my view models.
Example
I store in database 'Cars', so I have class called 'Cars' with properties like - Guid, Name, Color. In my view model I present on list those cars, so I will need collection of Cars which have properties like Name, IsSelected.
Of course I don't want to have one class in my project called 'Cars' with all properties, so I wonder if there is better option / naming convention than storing 'Cars' and 'CarsCollectionItem' in one folder 'Models' ?

I would think of it in terms of purpose:
Say the content of your database is the reference, so you should just have a DbSet<Car> Cars.
Now if you use MVVM, the Collections you use exist for some reason. The most generic reason would be to display them, so you could have Collection<DisplayedCar> DisplayedCars.
This is if you want to implement a façade to your Db object. The alternative approach would be to use Db objects in your view model.
var carsVm = new CarsViewModel();
var carVm = new CarViewModel() {Car = carFromDb};
carsVm.Cars.Add(carVm);
CarsView.DataModel = carsVm;
CarView.DataModel = carVm;
and then:
<Grid DataContext="{Binding MyCarVm}">
<TextBox Text="{Binding Car.Name}"/>
</Grid>

Related

Why isn't my ExtJS Store Association Working

I'm having issues. I want to use the nice ExtJS associations, but they're not working properly.
Issues:
no association showing in the model
no data showing up after load
What are the quirks to watch out for?
I recently went through a very painful learning curve with the ExtJS associations, and came across some useful articles, as well as my own gotchas. Here is the summary for those who run into the same pains.
Rules for HasMany Associations in ExtJS
Always put your Proxies in your Models, not your Stores, unless you
have a very good reason not to [1]
Always require your child models if
using them in hasMany relationships. [2]
Always use foreignKey if you want to load the children at will
Always use associationKey if you return the children in the same response as the parent
You can use both foreignKey and associationKey if you like
Always name your hasMany relationships
Always use fully qualified model names in your hasMany relationship
Consider giving the reader root a meaningful name (other than "data")
The child model does not need a belongsTo relationship for the hasMany to work
[1] The store will inherit its model's proxy, and you can always override it
[2] To make it easy, and avoid potential circular references, you can require them in app.js
http://extjs-tutorials.blogspot.com/2012/05/extjs-hasmany-relationships-rules.html
Rules for HasOne and BelongsTo Associations in ExtJS
Put the proxy in the model, unless you have a very good reason not to
Always use fully qualified model name
Always set the getterName
Always set the setterName
Always set the associationKey, if the foreign object is returned in the same response as this object
Always set the foreignKey, if you want to load the foreign object at will
Consider changing the instanceName to something shorter
The getter behaves differently depending on whether the foreign object is loaded
or not. If it's loaded, the foreign object is returned. Otherwise,
you need to pass in a callback to get it.
You should set the name property if you plan to override this association.
You do not need a belongsTo relationship for a hasMany to work
Set the primaryKey property if the id field of the parent model is not "id"
Sometimes you need to use uses or requires for the belongsTo association. Watch
out for circular references though.
Calling setter() function does
not seem to set the instance. Set object.belongsToInstance = obj if
calling the setter().
http://extjs-tutorials.blogspot.com/2012/05/extjs-belongsto-association-rules.html
Misc
If you're applying your data to a grid, make sure you call reconfigure() on the grid using the new store
Your "foreignKey" property will be applied as a local filter to the ExtJS store; if you see the data loading over the network, but
not showing in your grid, make sure your model has the foreignKey
value defined as a field, or the local filter will exclude the data
quiety. To test if this is the case, hook into the store's "load"
event and call store.clearFilters(), and see if your data shows up

Backbone.js page layouts & having model collection available globally

I'm working on a simple Backbone.js app for practice - a people quote database. (Person has many Quotes and Comments)
Questions
I would like to have two layouts.
One is a standard two column layout, with one column as a sidebar and the other as the content area. (I would like to embed the view into that column, and keep the sidebar static.)
The other would be a simple one-column layout for authentication purposes (I want to add authentication as well, since this is a practice project). A simple page with a login form. Obviously, this layout would only be used for one view.
How can I do this? Is there a plug-in that will make this possible/easy? (Essentially, is there an equivalent to the Rails layout system?)
On that sidebar, I would like to have a list of Person model objects, so a list of all Person objects must be available on each page. In Rails, I would accomplish this with a simple before_filter in the ApplicationController.
What is the best way to accomplish this?
I worked on a project which also required a similar layout structure. We had a rails app with two backbone instances on the frontend. To get our layout we used jQuery-UI-Layout. This will allow you to create multiple 'panels' which represent your sidebar and column. Then you can simply render your views into each panel, and they will be very nicely separated.
when you create your quotes and comments views, you can pass them the people collection so they have access to the person model objects.
so...
Say you have a 'main_view', this main view will initialize your jQuery ui layout.
$(this.el).layout({options})
where options will set the sizing on your Quotes and Comments panels. Then you create your views and pass them the 'people' collection, which is a collection of your 'person' models.
new App.Views.QuotePanelView({
el: $(this.el).find('#quote_panel'),
collection: people
})
Here people is a collection of people. And the same goes for the comments panel.
var people = new People([
{"name" : "James Cameron"},
{"name" : "Bat Man"},
{"name" : "Cool Guy"}
]);

cakephp: abstract classes, factory, return objects

I would need an idea or two how I would do this in cakephp (using latest version)
I am building a web based game where you will be able to collect Items
Without a framework I would have an abstract base item class that every item would extend to
And when displaying for example a inventory i would factory all items the user currently have and then return a object for each item.
classes...
BaseItem
WeaponItem
HealingItem
etc..
How would I do this in cakephp? Would I go for a model for each item class ... and how would i factor to get the object? ...
Assuming you're using a database as the data store, presumably you will use a single table for all items the player can collect? If so, you probably want a single Model class.
It's possible to have an inheritance hierarchy for models in CakePHP if you want. But you can often achieve sharing of Model logic using a Behaviour.

Lazy-loading large/complex model properties in Google App Engine

Let's say I'm modeling a website where a web page would be represented by a PageModel, like so:
class PageModel(db.Model):
name = db.StringProperty()
parentPage = db.SelfReferenceProperty()
content = db.TextProperty()
I'd like to be able to pull a list of all my page objects, in order to render menus, etc., but without having to pull in the content for all the items. How would you model this object so that you could pull in the content only when you needed it? Would it require a 1-to-1 reference relationship with a separate 'content' model? And if so, would you make the reference on the page object or on the content object?
You could move the content property into a new model (PageContentModel). I would implement the reference by having the parent of the PageContentModel be the PageModel (using the parent property of db.Model). This allows you to modify both of them in a single transaction (as they are in a single entity group).
One benefit of modeling things with the PageContentModel having a reference to the PageModel (as opposed to the PageModel having a reference to the PageContentModel) is that if you ever need content to be larger than 1MB you can do so by allowing each PageModel to have 1 or more PageContentModel objects and you would just split your content into 1MB chunks and write each chunk to a different PageContentModel instance. To be able to get the content back you would need the PageContentModel objects to have an "order" property associated with them so you can re-build your content in the correct order.
To query for the PageContentModel instances related to a PageModel you would use the ancestor filter like this:
PageContentModel.all().ancestor(page_model_instance)
As suggested by #Nick another way to do this would be to use the files api to write the content to a blob in the blobstore and then link that blob to the PageModel by having a BlobReferenceProperty on the PageModel. I have now had a chance to try this and it is working pretty well (despite it being an experimental feature). This would allow your content to be very large and, under the new pricing model, is actually cheaper than storing your content inside the datastore model.
Updated Feb 7, 2012 to include suggestion from #Nick about the blobstore.

Silverlight / .NET RIA Services - Exposing a custom property to the client

I have a table in my database called "Task". Task has the following fields:
- ID
- Description
- AssignedUserID
- TaskTypeID
I am accessing this table through a class that was created automatically after I used an ADO.NET Entity Data Model. I can load and show the fields mentioned above in a DataGrid in my Silverlight application. However, AssignedUserID and TaskTypeID are not very descriptive. So I decided to create a stored procedure that gets the tasks and the user and task type names through their respective lookup tables. This is where the problem lies.
I want to create some custom properties in the automatically generated "Task" class. The custom properties would be named "AssignedUserName" and "TaskType". I then want to make these properties available to my Silverlight client. However, I cannot seem to figure out how to get them exposed to my Silverlight client.
Can someone help?
Thank you
If your EDM is in the same project as the DomainService you can do this:
create a partial class on the Entity type, and add your calculated property in there.
name the file **.shared.cs
it will then be auto-shared with the client/Silverlight code.
Edit:
I was assuming that you could do this calculation in app logic rather than use an sp, which seems more straightforward to me.
If you do use an SP, you'll need to use the Function Import feature in the designer to map the SP to a function in the EDM. This function can then return entities, with properties mapped however you like.
An easier way would be to just use the object model: Have Task.AssignedUser and Task.TaskType objects off of your Task class. Map these to lookup tables in your db. This will work out-of-the box (assuming the Id's are FK's to those lookup tables).
So, a couple options:
use app-logic--properties in a partial class to return the descriptions
use the object model driven by FKs to lookup tables, then just access Task.AssignedUser.Name or Task.TaskType.Description
use a function import to access the SP and map the returned values to entity properties
1 or 2 being the best options IMHO.
Another approach might be to update your EF model to include the lookup tables, add Associations between the tables, add [Include]s in the (auto-gen'd) metadata class and let EF and RIA do it for you. Maybe.

Resources