The get_fields() function on the Meta object returns reverse relations. What is the best way to filter these?
I can see the _get_fields() function has a reverse parameter, but this is not exposed to a public API.
Related
Referring to this question: https://softwareengineering.stackexchange.com/questions/218391/arrays-vs-objects-in-view-template
I was wondering what are the best practices to pass data from controller to view?
I'm currently working on php/Laravel and using service layer between controller and models. I'm not using repository layer yet, so just getting eloquent object from models and passing them to controller then view. The format is not persistent, at some location the data is being passed as eloquent object/collection and at some points it's being passed in an associative array format.
We know, the best practice is that our view should know least about the backend code/structure. If we pass an eloquent object to the view, then our view even knows the field names in models. This way, changing one model field name will break our code till the view.
If we pass array then we can definitely such kind of information? There is also some concept about DTO (Data transfer object), how it can help in hiding our data from view? I'm looking for a way through which my front-end and back-end least depend on each other.
I used to have a single BLL class for each DataTable in my DAL.
Trying to follow OOP principles I divided each class to two classes as following:
class Item - represents a single item/row.
includes:
fields and properties according to the table's fields.
constructors - they don't access the DB
static Get method - returns a single Item from DB.
Delete method - deletes an Item from DB.
Update method - updates an Item in DB.
class Items - represents a sorted list of objects of class Item. key is the item's ID. includes:
field items_list of type SortedList
constructors - access the DB to fill items_list
GetList method - returns items_list
My questions:
1. As you can see, the Item class doesn't include any insert method, because I can't decide in which one of the classes it should be.
2. Is it ok to have a Get method in Items that will return an Item by its ID.
3. Is it ok to have Update and Delete methods in the Items class that will retrieve an Item from the items_list and then call the corresponding methods of Item.
Thank You.
You would benefit from reading about ORM and repository pattern. Once you pick a language you can use specific technologies for that, for example in C# there is NHibernate, Entity Framework, generic repository pattern are quite popular.
As you can see, the Item class doesn't include any insert method, because I can't decide in which one of the classes it should be.
Domain class shall not include any data access layer stuff. Keep it separate as these are different responsibilities. Have a look at the SOLID principles and Domain Driven Design.
Is it ok to have a Get method in Items that will return an Item by its ID.
No, not okay. Remove any data access members from the domain model classes.
Is it ok to have Update and Delete methods in the Items class that will retrieve an Item from the items_list and then call the corresponding methods of Item.
No, same reason as for the other ones.
In short, one class - one responsibility. Separate model from database interaction. Use separate generic classes to interact with the database, use ORMs. Have a look at couple of tutorials about that patterns and technologies.
Unfortunaetely the answer is 'NO' to the three question. I think that as oleksii explained in his answer, you are mixing different responsibilities in the same classes.
A class should have only one responsibility(Single Responsibility Principle).
Item should represent the data of one record so it should be limited to its properties.
Items should represent a recordset, a collection of Item (...that you might iterate). What you should get after a query, thus.
There should be at least a third class, call it DAO (Data Acess Object) or manager in charge of performing the DB operations such as Get, GetList, Update, Delete and Insert.
I just started learning backbone.js. I have a problem understanding how/when use models and collections. I found several tutorial online and each of them use different approach of building the application. There are cases where data is retrieved from REST API in a Collection object, in other examples in a Model object? I also noticed in every example json data was in format like
{'id':1, 'name':'some name'}.
My api returns a bit more complex data structure - something like {'message':'response message', 'error':'', 'data': [{list of data objects to be manipulated},{}]}. Is it possible to use such formatted data in backbone.js.
Well, yes, for both of your questions. Typically here is how the Relational database system relates to backbone.js:
Your model is a record from a table of the database.
Your collections are the table itself. So set of models make up the collection.
Views are used to define how your model should look and what it should do. There are views for your models, collections and intermediate data.
Your response if different; hence, you need to parse the data before it is set to the model, collection. Use the parse method and define the data key.
Is it possible to pass a collection of objects to a RIA Data Service query? I have no issues sending an Entity, an Int or an array of primitive types, but as soon as i declare a method like this
public void GetLessonsConflicts(Lesson[] lessons)
{
}
i get a compilation error
" Operation named
'GetLessonsConflicts' does not conform
to the required signature. Parameter
types must be an entity type or one of
the predefined serializable
types"
I am just trying to do some validation on the server side before i save the data. I've tried List, IEnumerable etc.
Thanks
I think the problem is actually the lack of a return value. As I understand it, you can identify DomainOperations by convention or by attribute. You're not showing an attribute so RIA will be trying to match it by convention.
For example, by convention, an insert method must:
have Insert, Add or Create as the method name prefix, e.g. InsertEmployee
match the signature public void name(Entity e);
a query method must:
be public
return IEnumerable, IQueryable or T (where T is an entity).
a custom domain operation must
be public
return void
have an Entity as the first parameter.
EDIT: See Rami A's comment below. I believe this was true at the time but I'm not currently working with this technology so I'm not current enough on it to update this answer other than to note that it may be incorrect.
Or you can use Attributes such as [Insert],[Delete],[Update],[Query],[Custom]. From my docs, all the attributes do is remove the requirement for the name convention - it's not clear from them, to me, what the [Query] and [Custom] attributes achieve.
As well as DomainOperations, you can define ServiceOperations (using the [ServiceOperation] attribute) and InvokeOperations.
This article might help (although I think it's a bit out of date).
Please read here and here to get a quick overview of my problem and to see exactly what I mean when I say Model Binding from Ajax.
Would it be a bad idea to make the foreign key fields nullable in order to allow for Model Binding from javascript?
For example, we want to bind to a Person object during an ajax call to... (The Person class is created from the Entity Framework)
public ActionResult Create(Person personToCreate)
{
//Create person here
}
If the Person had a Pet object that was a foreign key in the db, you can't pass the Pet object along with the other data from the ajax call. So unless the Pet is nullable in the DB, binding to Person wouldn't work.
So what I want to know is... in order to do Model Binding, should/can I null the db fields I can't pass from javascript? Or do I have to make a Custom Model Binder and bind to a "Flatter" version of the object in order to follow best practices? example of flatter version of the object:
public class SimplePerson() {
private string firstName;
private string lastName;
private string petName;
}
The reason I ask this is because a lot of my Entity Framework created classes contain foreign keys, which means I'll need to create a flat duplicate of nearly all of those classes, and it seems to go against the whole DRY principal.
I read over what you linked and posted, I can't really think of a good solution off the top of my head, but the whole concept of changing your underlying database for the sake of AJAX makes me uncomfortable. I know that's not a great answer, I'm struggling with several EF design issues right now myself, and there have been several times when I've been tempted to modify the database for the sake of the model, but doing that has always come back to bite me in the past.