Flask-Restless support and creates API's over models . can it also support custom collections?Lets say i design a datastructure or a object which i provide getter and setters can it be used as a model in Flask-restless.
Related
I'm new to MVC. I come from Webforms, by the way I was also using Servicestack ormlite.
I need to know if I can have an MVC project, but the Model section can be in a different assembly, so I can share this assembly with other projects (console app, web api, mvc project).
It is important that the assembly can have the Model section using the servicestack functionality for model(s) definition(I use servicestack ormlite for data layer), so here comes my other question, that servicestack's model(s) definition can it be used for the "views" in the MVC project? ie, the models syntaxis for servicestack is compatible with the strong typed models in the views MVC?
do you have a sample of:
models in external assembly
share models definition for DAL in servicestack(ormlite), and working in the views for the MVC project
Thanks in advance.
OrmLite is very flexible and resilient in what clean POCOs you can use with it, from a previous answer:
Clean POCOs
The complex Data Models stored in OrmLite or Redis doesn't suffer from any of these issues which are able to use clean, disconnected POCOs. They're loosely-coupled, where only the "Shape" of the POCO is significant, i.e. moving projects and changing namespaces won't impact serialization, how it's stored in RDBMS tables, Redis data structures, Caching providers, etc. You're also not coupled to specific types, you can use a different type to insert data in OrmLite than what you use to read from it, nor does it need to be the "exact Shape", as OrmLite can populate a DTO with only a subset of the fields available in the underlying table. There's also no distinction between Table, View or Stored procedure, OrmLite will happily map any result-set into any matching fields on the specified POCO, ignoring others.
Effectively this means POCOs in ServiceStack are extremely resilient and interoperable, so you can happily re-use the same DTOs in OrmLite and vice-versa without issue. If the DTO and Data models only deviate slightly, you can hide them from being serialized or stored in OrmLite with the attributes below:
public class Poco
{
[Ignore]
public int IgnoreInOrmLite { get; set; }
[IgnoreDataMember]
public int IgnoreInSerialization { get; set; }
}
Otherwise when you need to separate them, e.g. more fields were added to the RDBMS table than you want to return, the DTO includes additional fields populated from alternative sources, or you just want your Services to project them differently. At that point (YAGNI) you can take a copy of the DTO and add it to your Services Implementation so they can grow separately, unimpeded by their different concerns. You can then effortlessly convert between them using
ServiceStack's built-in Auto Mapping, e.g:
var dto = dbPoco.ConvertTo<Poco>();
The built-in Auto Mapping is also very tolerant and can co-erce properties with different types, e.g. to/from strings, different collection types, etc.
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'm trying to understand Magento and I was wondering if someone can give me any insight on this topic
Describe the basic concepts of models, resource models, and collections, and the
relationship they have to one another
Resource Models are objects that contain code which fetches data from a datastore. In practice, this means a resource model is the object which contains the SQL building and fetching code, as well as references to objects which connects to the main Magento database.
Models are objects which contain database agnostic code for interacting with a "type" of data. In traditional data modeling terms your model objects contain the business logic for a particular kind of object (kind of object meaning Product, Customer, etc.).
Important: In addition to the above definition, parts of Magento code use "Models" as generic object that contain business logic unrelated to data. These "models" should be thought of as plain old objects, just instantiated through Magento factory pattern. Models that inherit from Mage_Core_Model_Abstract are the former — models which do not are the later. This post assumes "model" refers to the former. I've also started referring to these as Magento's CRUD models.
A Collection is an object which contains code that fetches a group (collection, array, list, etc.) of model objects. Since it generates SQL to do this, it's also considered a resource model and is instantiated with the Mage::getResourceModel method, (Although collection objects inherits from a different chain of classes than the normal resource models. These are not the design patterns you are looking for). Collection objects also implement certain standard PHP interfaces, and may be used in foreach loops to iterate over their results.
A Magento model object contains a reference to a resource model, which is uses to load its data. There's an individual resource model object for each model object. i.e. A Product Model has a Product resource model.
A Magento model object may also be used to instantiate a collection object. Collection objects are also typed to match their model objects. A Product model may be used to instantiate a Product collection object.
A collection object creates SQL to fetch a group (collection, array, list, etc.) of objects, and it also contains code to assign data to the main model object. Because this code is slightly different than the code in a model's resource model object, there are often slight discrepancies between models loaded directly or via a collection. For example, a collection does not call each model's _afterLoad method, or an EAV collection will not load all attribute data by default (unless addAttributeToCollection('*') is used). A lot of Magento development is tracking down and account for these discrepancies.
Finally, there are places in the Magento source code that deviate from the above. For example: Report collection object are free standing — they are not ties to a specific model class. Keep the above in mind, but be ready for specific Magento modules to surprise you.
Too much to type :) Alan Storm wrote great article about magento model basics
I have a "Post" entity and I want users to vote for those posts. Votes by authenticated and anonymous users are being stored in separate DB tables, so there are two separate "VoteAnonymous" and "VoteAuthenticated" entities which implement the same interface.
Now I've got problem with defining a reference in a "Post" entity and its "targetEntity" option. I wonder if there is any way Doctrine2 could pick one of the polymorphic classes as its field's target entity.
Thanks for any help.
P.S. I'm not able to redesign the DB, there's a ton of legacy code that lies upon this data structure.
Doctrine supports inheritance, so you should create two different entities that share a common parrent, say AbstractVote, which defines all properties.
See this answer - it contains an example of such structure.
I am wondering how the models in code ignitor are suposed to be used.
Lets say I have a couple of tables in menu items database, and I want to query information for each table in different controllers. Do I make different model classes for each of the tables and layout the functions within them?
Thanks!
Models should contain all the functionality for retrieving and inserting data into your database. A controller will load a model:
$this->load->model('model_name');
The controller then fetches any data needed by the view through the abstract functions defined in your model.
It would be best to create a different model for each table although its is not essential.
You should read up about the MVC design pattern, it is used by codeigniter and many other frameworks because it is efficient and allows code reuse. More info about models can be found in the Codeigniter docs:
http://codeigniter.com/user_guide/general/models.html
CodeIgniter is flexible, and leaves this decision up to you. The user's guide does not say one way or the other how you should organize your code.
That said, to keep your code clean and easy to maintain I would recommend an approach where you try to limit each model to dealing with an individual table, or at least a single database entity. You certainly want to avoid having a single model to handle all of your database tables.
For my taste, CodeIgniter is too flexible here - I'd rather call it vague. A CI "model" has no spec, no interface, it can be things as different as:
An entity domain object, where each instance represents basically a record of a table. Sometimes it's an "anemic" domain object, each property maps directly to a DB column, little behaviour and little or no understanding of objects relationships and "graphs" (say, foreign keys in the DB are just integer ids in PHP). Or it can also be a "rich (or true) domain object", with all the business intelligence, and also knows about relations: say instead of $person->getAccountId() (returns int) we have $person->getAccount(); perhaps also knows how to persist itself (and perhaps also the full graph or related object - perhaps some notion of "dirtiness").
A service object, related to objects persistence and/or general DB querying: be a DataMapper, a DAO, etc. In this case we have typically one single instance (singleton) of the object (little or no state), typically one per DB table or per domain class.
When you read, in CI docs or forums, about , say, the Person model you can never know what kind of patter we are dealing with. Worse: frequently it's a ungly mix of those fundamentally different patterns.
This informality/vagueness is not specific to CI, rather to PHP frameworks, in my experience.
I'm attempting to implement a specific type of version control for several of my models (fundamentally different from what acts_as_versioned and vestal_versions provide). What is the best way to implement a virtual ActiveRecord model that's driven by multiple conventional ActiveRecord models, where the model data do not exist simply as one row within one table?
In other words, how might one create an ActiveRecord model where the CRUD methods are overridden and call appropriate methods on multiple underlying ActiveRecord models?
I'd recommend the new book "Crafting Rails Applications" from the Pragmatic Programmers
http://pragprog.com/titles/jvrails/crafting-rails-applications
The second chapter does something very similar.. all that's needed on top of that, is to
implement something similar to activerecord-3.0.3/lib/active_record/persistence.rb , which
acts as a go-between from your virtual model to the underlying persisted models.