I am new to NestJs and GraphQl, I am learning going over some tutorials. It appears to be an inconstancy in the usage of the terminology model or entity. The nestjs schematics resource generator for graphql code first produces entities, yet the example shown on their website use models.
produces entities:
nx generate #nestjs/schematics:resource generated --language=ts --type=graphql-code-first
uses models no mention of entities in code first approach
https://docs.nestjs.com/graphql/resolvers
which one terminology is most appropriate?
Thank You,
Michael
Both are generally correct. It comes down to naming preferences.
I view entities as database entities, or database table maps. They map from your database data to a class representation that your code will understand. Models can also be used for this, which I believe is the term that sequilize and mongoose prefer to use.
Models, as described in the docs you linked, are generally your DTOs, your schema objects that you expect the API to accept and respond with.
You'll notice that the generator also generates two #InputType() files as well, which will be more closely tied to your incoming DTO while the entity.ts will be closer to your response DTO.
So, both are correct, and it comes down to naming preferencec.
Related
Quick question, what is the difference between Eloquent: API Resources and Fractal?
To me, it looks like the same thing?
Both are used to transform API json responses to standardise the response structure.
However, API resources is inbuilt in Laravel and it's very easy to use. Fractal was the preferred way to go when API resources were not in-build in Laravel. Fractal has some methods which make it little extensive as compared to API resources.
But if you consider the core functionality, both are same with different syntactical sugar.
Most of the things which were in fractal, you can do natively in Laravel now. Plus API resources eliminate the need of any extra installation and setup. The nomenclature is very easy in API resources to start with
both of them are created for one job but their solutions are different in many ways.
Relationships:
in fractal you can easily add related models to the response. also, you can control when the related models should be presented in the response . (default include vs Available include)
for example your client can use ?include=rate to get the rate model from an article when needed! consider that, the fractal will eager load your relationships when you forgot to load it.
in API Resources you have no control over relationships and you should decide to have relationship or not in the first place. otherwise, if you forgot to eager load data for it, it will cost you too many queries to load related model (1+n problem).
Serializer
in basic usage of api resource you have no control on how data will map to final response.
for example if you want jsonnapi specification for your responses, you should manage all of the works by yourself. but in fractal you have it in the first place.
as a conclusion
i recommend you to use fractal in this case. (or use dingo package for api but consider complexity of dingo !!)
Imagine, for example, you have front-end and back-end applications. They are both written in different technologies, lets say backend is in python using django and front end in typescript using angular.
Now there will be some data that will need to be shared between those two. Enums, serialized dictionaries of class instances or names of some fields.
Very quickly a problem arises of data structure duplication and possibility of desynchronisation. (E.g. you have to have to exact enums on both platforms)
I was wondering are there any "best practices" out there?
Like XML based standardizing data or something?
Could you point me to some books / articles?
Could you share your knowledge of how you do this?
Thank you.
I know two ways to solve this obstacle:
Write your own clients for consumers.
Use model contracts like RAML and generate models from declarations.
And you don't have to have the same exact enum or any other class on both platforms. There should be a layer that consumes and returns any data to the outside world(external client). This layer has its own models. Everything that lies below should have their own. You can have many small objects stored in database, but return to the client huge aggregates and that would be different models. Read about data models in standard N-tier application.
I've worked with OOP for a while now, and have gotten into the habit of creating classes for 'things', such as person, account, etc. I was coding in Java for this.
Recently I begun to work with MVC (in PHP), and I've come to realise that, contrary to what I originally thought, the model is not like an OOP class - feel free to correct me if I'm wrong, but my understanding is that the model is simply an interface between the controller and the database (maybe with data processing - more on this below). My reason for thinking this stems from my recent messing around with the CodeIgniter framework for PHP. CI doesn't allow for instances of models. Rather, it's a singleton pattern, and in most tutorials I've seen, it's used only for database queries and sometimes some static method.
Now, coming from OOP, I've gotten into the habit of having classes where the data is stored and able to be manipulated (an OOP class). My issue is that in MVC, I'm not sure where this takes place, if it does (I initially thought 'class' was synonymous with 'model'). So, I guess what I'm looking for is someone to explain to me:
Where does the manipulation of data (business logic) take place? I've read many articles and posts, and it seems some prefer to do it in the controller, and others in the model. Is one of these more correct than the other in terms of MVC?
Where/how do I store data for use within my application, such as that from a database or JSON/XML files returned from an API call? I'm talking things that would usually be attributes in an OOP class. Does this even still take place, or is it straight from the database to the view without being stored in variables in a class?
If you could link me to any guides/sites that may help me to understand this all better, I would appreciate it.
Representing MVC in terms of classes, you can say that:
Model - A class which stores/provides data.
View - A class which provides functionality to display the provided data in a particular fashion.
Controller - A class which controls that how the data is manipulated and passed around.
MVC design is adopted to provide facility to easily replace any of the module (Model/View/Controller) without affecting the other. In most cases, it is the view which gets changed (like same data represented in form of graphs, chats) but other modules must also be made independent of others.
This is an interesting question, and you often hear contrary things about how clean and stripped down models should be vs them actually doing everything you'd think they should do. If I were you I'd take a look at data mappers. Tons of people much smarter than I have written on the subject, so please do some research, but I'll see if I can summarize.
The idea is that you separate out your concept of a model into two things. The first is the standard model. This simple becomes a property bag. All it does is have a state that often reflects your database data, or what your database data will be once saved, or however you use it.
The second is a data mapper. This is where you put the heavy-lifting stuff. It's job becomes providing a layer between your pure model, and the database, that's it. It talks to the database, retrieves data specific to your model, and maps it to the model. Or it reads the model, and writes that data to the database. Or it compares the model's data with that of the DB.
What this does is it allows each layer to concern itself with only one thing. The model only has to keep a state, and be aware of its state. Or have some functionality related to the model that does not involve the database or storage. Now the model no longer cares about talking to the database which is hugely freeing! Now if you ever switch to a different database, or you switch to cookies or storing things in files or caching or any other form of persistence, you never need to change your models. All you have to change is the mapping layer that communicates between your models and the DB.
In my app I have my domain layer and web interface (other layers I will not go into details).
My views, working with ViewModels objects, and the database persist domain objects.
To convert a ViewModel object to a domain object I use AutoMapper.
The problem with the working Breeze is that when I will create a new object var newCust = manager.createEntity('Customer', {name:'Beta'}) this is a domain object, and should be an ViewModel object.
Not all, but in some cases the ViewModel is not similar to the object domain. For example, collections of objects in the domain are: ICollection<Person> while in view model are ICollection<int> int is a PK of person.
Question
How to working with breeze in these cases?
How to make the metadata also manages the structure of my viewmodels so I can create objects of type my ViewModel?
#ridermansb - Because you mentioned AutoMapper, I will assume that your mapping is taking place on the server. You want your server API to expose "ViewModels" (in this case you might call them DTOs) rather than the domain model objects. Sometimes your ViewModels mirror your domain objects exactly; sometimes they don't.
Your client only sees what your API exposes. If this is a BreezeJS client, you will likely treat the ViewModels as client-side entities. They are Breeze entities in the sense that you expect Breeze to query, cache, change-track, and validate them. BreezeJS doesn't know whether these "entities" correspond to server-side DTOs or server-side business objects.
Of course if you're using DTOs/ViewModels, your server code is responsible for translating between the DTO form and the domain object form. Presumably this logic lies somewhere in/between the server-side API layer and the domain layer.
If you have chosen this architecture, you have chosen to deal with the bi-directional translation between ViewModels and domain objects and have embraced all the complexity and hassle that entails. I have no words of advice for you on that score.
So let me rephrase and narrow your question: "How can I get metadata that describe the object model exposed by my server-side API?"
My favorite way (assuming a .NET server) is to let EF do it for me. I create a DbContext that references NOT my domain model classes but rather my ViewModel/DTO classes. Of course these classes would not actually map to a real database. No problem; they don't have to. You will never use this DbContext to access data. You will only use it to generate metadata. You are using EF as a design-time, metadata-generating tool ... and that's it. This is an efficient maintainable approach.
I hope to demonstrate this technique "soon" but I've been mighty busy recently so no promises.
Alternatively, you can write the metadata by hand as described here.
Can someone explain these 3 concepts and the differences between them with respect to an MVC framework along with an example. To me these appear almost equivalent, and it seems they are used interchangeably in some articles and not in others.
The terms are a bit vague I agree. I would use domain to refer to the business area you are dealing with. Like banking or insurance or what not. Then you have domain models. These are the things you deal with in that business domain, like for domain of banking you have accounts, customers, transfers etc. I would use term entity for referencing the class/POJO or the persisted / concrete version of a model.
What probably confuses you here is that in the term MVC, the model is a concrete thing, but it references the data model used to represent some presentation in a web GUI so don't get that mixed in with the above explanation.
The terms you are confused about are: "domain objects", "domain entities" and "model objects". While usually used interchangeably, the domain entities and model object can also be instances of active record pattern (basically: domain objects with added storage logic).
In ordinary domain object there is no storage logic. It gets handled by data mappers.
The term "model objects" comes from Fowler's books (read PoEAA for more details), and, IMHO, is part of the confusions MVC, because the entire model is an application layer (MVC consists of it and presentation layer), which contains those "model objects", which are usually dealt with by services (in that image, the model layer is all three concentric circles together).
I much prefer to use "domain object" term instead.
The term "domain entity" (or "entity object") is usually used when author implies that the object is a direct representation of a storage structure (more often - a database table). These are also almost always implementations of active record.
P.S.: in some articles you would also see term "models" (plural). It usually is not directly related to MVC design pattern, because it talks about Rails-like architecture, where "models" are just active records, that get directly exposed-to/created-by controller.
.. not sure whether this confused you more
For the record. In practical purpose, domain and model are the same, while entity is also a domain/object that would be used to store in the database.
Some people are tried to re-explain such topics but none of them are canon.
The difference is that, in the world of Java, Domain is more used, while in the world of C#, Model is used (and MS encourages his use) but its just convention and you can use both.
In the same, concept, Value Object (VO) is used by the people of Java, while DTO for the people of C# even when both are practically the same. Also POJO (Java) vs POCO (C#), Packages (Java) vs NameSpace (C#), Setter and Getter (Java) vs Encapsulation (C#)
Both domains and models are classes. How the class is use distinguishes if it should be classified and put in a domain or model folder. If the class is going to be used ONLY in the view, put it in the model folder. If the class is mapped to a database object, then put it in the domain folder.