feat: add explaining in readme

kauemurakami · kauemurakami · commit 20fb4961c0d2 · 2020-09-09T14:13:48.000-03:00
diff --git a/README.md b/README.md
@@ -79,11 +79,53 @@
 
 - main.dart  
 # main file
-# proposed by william Silva 
+# proposed by william Silva and Kauê Murakami
 # We also have a version in packages to vocvê that is used to the good old MVC
 
 examples available in this repository: getx_pattern_site and getx_example
 ```
 
+### Explaining
+#### Data
+Here we won't have much to discuss, it is just a repository where you will abstract / package EVERYTHING related to your data, your models, your repositories and data providers. If you choose to use the module version, Data will have the same role, leaving your data available for all your modules, leaving only what is vital for your module in it !!  
+This was designed so that you can keep your directory structure as small as possible when working with flutter, and at the same time, be intuitive and didactic to speed up your learning curve.
+#### Provider
+obs: In some other structures, the term 'provider' can be approached in various ways, but here, it exists only and exclusively, to make http requests or persistence in a database. If you use both, create the respective directories and / or files within it.  
+If there are many requests, in a single file, you can choose to separate by entities, or keep it in the same file, this is a personal choice and it is up to each programmer.
+#### model 
+In our model class we will have our attributes and two methods, toJson and fromJson responsible for converting our object to json or a json to our object.  
+Generally when we work with API's, we use these methods to create objects from our api's response, or create a json to send to our api.
+#### Repository 
+It is responsible for separating its entities, basically, entities are all "tables" of your database that will interact with your provider.  
+The repository aims to abstract and separate its data source from its controllers, thus having a single point of failure, that is, if you ever change your project's api or database, just change your providers files, with no need to change the repository, as it is only responsible for calling the provider function, there is no logic there.  
+ex Imagine that you have a product selling app that only has customers and products from an establishment.  
+We can easily identify our entities by asking us a question.  
+Will I receive and / or send data from that entity? If the answer is yes, then it needs a repository.  
+In our example we would have three repositories, UserRepository, ProductRepository, EstablishmentRepository.  
+Sometimes, we can remove these entities based on our classes, but often there are auxiliary classes that are not necessarily in your database or api, so we prefer to base ourselves on what really interacts with your database.  
+Dessa forma, tiramos muita responsabilidade do nosso controller, ele não precisa saber de onde vem os dados, apenas consumi-los, outra vantagem é que o repository faz a nossa ligação Controller <-> Dados.
+Tendo assim, uma melhor organização, deixando o código compreensivo e é extremamente fácil a manutenção, de forma intuitiva.
+### Module
+The modules will contain our respective Binding, Page, Controller.  
+This makes the project shorter and easier to maintain.
+
+#### Controller
+Controllers are the vital part of your application, in which you will create your .obs variables which will store values ​​that can be changed during the application.  
+Your controller is also responsible for consuming your data>, through its repositories, which in turn only perform data calls from your providers
+Rule: Every controller must have one, and only one, repository, which is an attribute required to initialize your controller in your GetX widget.  
+If you need data from two different repositories on the same page, you must use two GetX widgets. We recommend that there is at least one controller for each page.  
+There is only one exception so that you can use the same controller for several pages, and it is quite simple:  
+
+IMPORTANT  
+You can use a controller on several pages, only and exclusively, if the data on all pages, consume a single repository.  
+
+The purpose of this is to get you to use GetX and take full advantage of its power, so whenever you need to manipulate two entities, you will need two different controllers and a view.  
+Why? Imagine that you have a controller with two repositories, and that controller is being used with a GetX widget on a page, using data retrieved by the controller from the two repositories.  
+Whenever an entity is modified, the controller will update its widgets responsible for the two variables, one of which did not need to be changed. So separating a repository by controller, it can be a good practice when working with the GetX widget, having a responsible controller for each widget, which somehow shows this information from them, rendering only the widget that had its .obs variable changed. .
+#### Bindings
+Ideal for your dependency management, bindings can initialize your controllers and repositories, apis and whatever you need, without having to call them directly from View with GetView<YourController>!
+#### Page
+Your module interface using YourPage extends GetView<YourController>.
+
 ![](images/rocket.png)
 
