In Yii PHP framework, one has ability to create modules. As per Yii's official documentation here is definition of the module:
A module is a self-contained software unit that consists of models,
views, controllers and other supporting components. In many aspects, a
module is similar to an application. The main difference is that a
module cannot be deployed alone and it must reside inside of an
application. Users can access the controllers in a module like they do
with normal application controllers.
Let's say we have a huge aplication and we have to create front-end and backend. In this case, is it better to create frontend module, and backend module and use them, or it is better to implment frontend as one Yii application, and backend as second Yii application.
I'm asking this because if you look at Yii's 2 advance template, there three are different applications (common, backend, frontend), but they are not implemented as three different modules, and my question is why?
Is app is going to be slower when you use modules and what are pros and cons of using modules?
Yii2 advance template has 3 different applications however they are frontend, backend and console (not common).
is it better to create frontend module, and backend module and use them?
The answer is "it depends". Lets take some examples:
I have a "users" section in the backend that tells the system what can each user change in the backend. I use this in multiple applications with no change at all so I have created a user module that I can just insert wherever I want. It is the simplest module because I never use it for the frontend.
a blog module, the blog module is a little more complicated as it has a place to manage the blog (this part is in the backend) and the posts and comments shown in the front section (this part should be in the frontend). However I still want to be able to plug it in multiple applications. My solution was to create some folders in the actual module (I actually created the same structure frontend / backend / common). The logic is the same, in my website frontend I use what you find in the frontend folder of the module, the common holds the things that I use in both the frontend and backend (like some models) etc. Different application will use the same frontend controllers / widgets but make sure you allow the views to be changed.
The answer to use or not to use modules is actually the same answer to "Will I use this in other applications and can it function without the rest of the application?" A module should NOT be tight coupled with the rest of the application.
The idea of the modules in that they almost autonomous.
At the stage of application development you must highlight from it all stand-alone elements.
For example, I have a large CRM. I need a user module (includes all models associated with the user, controllers, display
components and their configuration - for example the rules of routes). There is also an administrative module.
There CRM module and a module for corporate events and meetings schedules.
And about 3-5 independent modules - for example internal communications module,access control module and module of electronic payments.
The convenience is that the all modules are self-contained. They have their own MVC- sets, sets of widgets and configurations.
And they can be moved from one project to another without much effort.
Here's another interesting modular system:
There are resource with various functionality. It can be divided into modules. Each module file should implement a modular interface (you need to write it).
For example, I want each module to provide its own widget for menu.(Drop-down list or just a button) and its own widget for dashboard.
Also in the module file specified access to various actions, etc.
There is a basic component,that prior to the step of rendering polls all modules at their regulated functionality and builds on its basis the menu, dashboard and other widgets.
The main thing with this approach, keep in mind, that everything that module provides must be prepared by the modular functionality(models, widgets) not to disrupt the modular autonomy.
Related
I'm new in this area, however I would like to know, if it is better to put api inside my project, or create one back-end separate and pull into the project. I know if I use a separate back-end I will have to buy 2 hosting, if I use it within my project it would be one.
back-end integrated into the project
back-end separate
I tried to do both ways, and apparently it worked, but I would like to know if it is recommended to put the back-end inside the front-end
It depends on your needs and budget. if your project requires a lot of data processing or complex business logics it may be beneficial to separate your API from the front-end. However if your project is simple and doen't require a lot of data processing then it maybe more cost-efficient to host the API within your Next.js project with a single server.
I have just picked up Vue and am trying to figure out the best way to structure this project.
Requirements:
A basic MPA (traditional site) with about 6 pages. This will be static info.
There will need to be a login section where customer will transmit data via form. Payment will happen here as well so will need to be secure.
My question is how should I be using Vue here? (I've already used VueCLI to scaffold out the project)
Should I:
A) use it for some components (Navbar, buttons, forms, etc) and keep structure traditional? How would i build out the User Dashboard to submit form info in this case - just as a new page?
B) or should I build this whole site as a SPA and have the new 'page' info loaded in on click? This would be easier for the login section?
One thing that may be clear on reading this is I don't understand well how the site will recognize users and deal with logins. Would this be easier if it were structured as a SPA? (more secure?)
(Also, I'm using this site to teach myself front-end development, specifically would like to learn more about building SPAs - so I realize I could use a web editor or easier solutions, but want to learn how to do a lot of this from 'scratch')
From what you've described it is entirely up to you. Both SPA or MPA would work fine and either would be totally reasonable given the requirements.
Have you worked with Vue-router before? SPAs don't need to appear as a single page to the user. They can still function as an MPA with different routes, page files, permissions, etc.
If you are hoping to use this project to teach yourself front-end web dev and know you have a particular interest in learning about SPAs, I think that is your answer.
I would go with an SPA and set up vue-router to manage your routes, and pages.
Currently I've been tasked to create a bunch of small-to-medium applications, each of them having some common functionality.
Implement a preapproved boostrap-based graphical design. Therefore, they will use the same assets, images, css and JavaScript components.
Share the same licensing-based mechanism. An application service will be built where it will scan a file or database to get the number of licenses available for each app, thus granting or denying access to users. The only thing that varies is the name of the application instance itself.
Use AzureAD authentication.
Each must use the same authorization mechanism. A claims-based mechanism will be built to retrieve the claims from the database, given a user AAD account.
Each must share the same administration console.This console will be the one needed to populate user information and common catalogs.
A service will be built, to show toast notifications within the apps.
An email notification service will be built, to send emails to users when triggered by business rules.
And some other, less important features, but these are the core ones.
A first, perhaps naïve approach, was to create an ASP.NET Core 2 solution for each application, and implement the shared functionality in a sort-of Core assembly that can be shared by each app. However, while this could work for points 2 to 5, I'd still be repeating the graphical UI design for each app (basically, copying the wwwroot folder as well as the shared razor views five times). So, a change tomorrow in a CSS would have to be replicated five times.
Another approach would be to create a single ASP.NET Core 2 solution, implement the shared functionality and the UI, and then use the "areas" feature o ASP.NET Core 2, each area being a different app. The problem to this approach is shipping the app: if I have to install the five apps in a customer's server, no problem. If I have to install, say, only two apps, then I'd have to ship the five apps anyway and find a way to disable the other three apps.
So, I'd like to know if there is a feature in ASP.NET Core 2 for handling this type of scenarios, or alternatively, what are industry-standard architectural designs that could apply here.
In Windows Presentation Foundation with Unity, I can create a common shell, and then load modules in that shell, within the same shell window. So, using configuration files, I can add or remove modules as I see fit. What I'm looking is something similar in concept. I do not want to create five ASP.NET Core solutions and copy-paste the wwwroot folder and implement the same mechanisms of authorization, notification, email, etc., but rather, find a way to load the core, common features and then load additional features.
Thanks in advance.
I have started to work on a greenfield web project which will use ASPNET Core and Aurelia. I cannot find a definitive best-practice approach to structuring this on the client. My current thinking is that each app feature will be be a separate Aurelia application, i.e. when a visitor clicks on the link "Accounts" the browser will make a server request to https://example.com/accounts. This will return a single HTML page which bootstraps an Aurelia app just for accounts. All the accounts interaction will be delivered using Aurelia. Similarly, if the visitor then clicks on "Dashboard", another server roundtrip will bootstrap the "Dashboard" Aurelia app.
Is this a good way of approaching the problem? I have some concerns around application state - in that there will be cross-cutting concerns and data which I don't want to keep round-tripping to the server every time I need it, e.g. audit logs, user information.
I see that Aurelia has the concept of Features - semantically this is exactly what I want as each of these areas of the app will be delivered as a feature. However, I cannot find any good examples of the use of Aurelia features.
Any comments or experiences in similar projects most welcome.
I don't know if it's the 'best' way of doing it but a lot of the applications I build are user / admin type products.
Rather than building an application for each side I take advantage of child routers and structure my application with a page based convention as described here:
https://ilikekillnerds.com/2015/10/how-to-structure-an-aurelia-application/
I am new to Yii framework, and just came across module, extension & component inside protected folder.
Can anyone please differentiate all these theoretically as well as practically also.
Components are the classes which can help you write the business logic on the basis of your models. Suppose all of your model files are using the same logic, So that logic can be written inside component instead of writing for each controller.
Extensions are like the libraries, which basically are not dependent on your models, and hence can be reused anywhere in current or later projects. For example writing any email extension.
Module is a self-contained software unit that consists of models, views, controllers and other supporting components. In many aspects, a module resembles to an application. The main difference is that a module cannot be deployed alone and it must reside inside of an application. Users can access the controllers in a module like they do with normal application controllers.
I hope it will help you.
Adding my 2 cents here...
Component
your own class file you want to do something with, specific to this site only. Examples are zip compression class in an uploader app, custom encryption algo for some security app
Extension
An external class file or group of files which are re-usable, often provided by 3rd parties. Examples are facebook connect library you or someone else built, api library from ebay.com to get listing, rss reader library to read from google etc.
Module
A mini- yii based site which serves as a subset of your site,can also be reusable in other applications or is build independent to make yii even more modular. Examples are , a forum module that is independant of the site but uses only logged in user info, a user authentication module which contains integration with several sites like openid, facebook and google