MVC with React Native
Software are just like any other constructed objects, they have underlying structure. We usually call this architecture, deriving from the term used by infrastructures. A function in a software may be seen like a single brick in a building. You don't need to think so much for placing a single brick, but if we need to construct something from hundreds of bricks, we're gonna (in any way) use some architecture to place the bricks.
Software Architecture
A software architecture defines its components, how they are grouped, and relations between those components. Software architecture may be sometimes used interchangeably with system architecture, but some others differ these two. System architecture specifically talks about underlying systems and interactions between those systems. Software architecture talk about higher level structures.
We can just develop our codes in some messy way, but then it'll be harder to maintain. Probably we don't even realize that we unconsciously implement particular architecture as we learn about software development. There are actually some motivations that may help us get a hold on why we should think about software architecture in our software:
- A defined software architecture gives us a glimpse of how a software which implements it will work. We can know its behaviors, how its components interact, how many resources we need, and also its risks. We can see whether an architecture will work well for our software even before we start coding. We can also foresee possible risks in using an architecture, thus makes us aware of what to anticipate.
- A software architecture can also be reused. If we already have a working architecture, we can "copy" it to make another software which need similar underlying structures.
- Using a clear software architecture may also help us in creating maintainable codes. By understanding the behavior and concept of the software architecture used, we may more easily discover where the bugs or issues are. We can also determine which part may or may not increase our software's performance.
- A software architecture help us foresee risks. We may predetermine which parts of the structure may need more attention or optimization. For example, MVC architecture which separate its View from its Controller through the network may has performance issue if the internet connection is poor, so we can probably reduce interactions that need internet connection or maybe give some error handling.
MVC in my PPL Project
My team and I are working with React Native for an android application, named Talenta Kiosk, in our partnership with Mekari. This app is a kiosk version of the original Talenta Mobile app, an app for managing HR processes, such as attendance or time-off request. We actually didn't really realized that we use MVC at first, but by following some practices from the internet, I find that we're actually using MVC here.
MVC stands for Model-View-Controller. It has three super components, which is listed in its name. Model is the interface that handles data and requests on those data. View is basically the interface which interacts with users, usually Graphical User Interfaces. View displays informations, interactive interfaces, and/or data from Model. Controller is connector of View and Model, in which works by handling requests from View and make corresponding request to Model, vice versa. See diagram below for illustration.
Source: https://i.stack.imgur.com/0H9Vj.png
By interacting with the interface (View), an event may trigger the View to send corresponding "request" to Controller. Controller is the main "brain" here and it controls what further step to do after receiving "requests" from View. This may result in Controller create a request to Model. Model then prepare what is requested, or even modify some data. Then any changes in Model can affect View to change behavior or displayed information. Model can return a response to Controller, and just like when Controller receives request from View, it can process some further instruction to View.
My team and I only work on the front-end side of the app. Back-end service(s) are already provided by our partner. We don't really know underlying implementations in the back-end service(s) as we only get "API documentation". Simple illustration of my team's app can be seen below.
My team only developed the "View" side of the software. The UI components are displayed in a kiosk device. User interacts with this device and creates UI events. React Native here works as what I would call "UI logic". It listens and handles events from users and do some simple logic afterwards (simple because UI should not really has any programming logic as it is back-end's job). This UI logic then may send some requests to the Controller through API calls (with internet connection) to Talenta's back-end. We don't get to see the underlying components of Talenta's back-end service(s) so I'll call it a magic box. This magic box should comprise of Controller (the API called) and Model (the database service, and yes I do believe it exists there). Regardless of how the Controller and Model interacts, the Controller will then return response to our UI logic and then action(s) are done to UI page (update display, do navigation, etc.) as a result.
This implementation of MVC is quite commonly used and have some benefits. It separates View from Controller and Model, so front-end developers (like my team) can work (quite) independently from the back-end developers. Independent doesn't mean no communication at all, though. MVC also help my team (and our partner) to discover where an error or bug resides. Wrong data content displayed may be a problem in Model or Controller, but wrong data representation displayed may be View's problem.
So, yeah.
That said, I don't have much more to share here. There are still much more architecture style to explore, and not every style is applicable to our software. It may be exhausting to learn more different architectures, but understanding the use of one may help us build a good software. MVC may be good for my team's case, but may not be enough for yours. Thank you for reading, and have a nice future!
References: