客服电话
APP下载
迪恩网络APP
随时随地掌握行业动态
官方微信
扫描二维码
关注迪恩网络微信公众号
开源软件名称（OpenSource Name）：lucidarch/laravel开源软件地址(OpenSource Url)：https://github.com/lucidarch/laravel开源编程语言(OpenSource Language)：PHP 82.3%开源软件介绍(OpenSource Introduction)：LucidThe Lucid Architecture is a software architecture that consolidates code-base maintenance as the application scales, from becoming overwhelming to handle, gets us rid of rotting code that will later become legacy code, and translate the day-to-day language such as Feature and Service into actual, physical code. Read more about the Lucid Architecture Concept. If you prefer a video, watch the announcement of The Lucid Architecture at LaraconEU 2016: The Lucid Architecture for Building Scalable Applications - Laracon EU 2016Join The Community on SlackIndexInstallation8.xTo start your project with Lucid right away, run the following command: This will give you a Laravel 8 installation with Lucid out-of-the-box. If you wish to download other versions of Laravel you may specify it as well: 7.x6.x5.5IntroductionDirectory StructureComponents
ServiceEach part of an application is a service (i.e. Api, Web, Backend). Typically, each of these will have their way of handling and responding to requests, implementing different features of our application, hence, each of them will have their own routes, controllers, features and operations. A Service will seem like a sub-installation of a Laravel application, though it is just a logical grouping than anything else. To better understand the concept behind Services, think of the terminology as: "Our application exposes data through an Api service", "You can manipulate and manage the data through the Backend service". One other perk of using Lucid is that it makes the transition process to a Microservices architecture simpler, when the application requires it. See Microservices. Service Directory StructureImagine we have generated a service called Api, can be done using the
We will get the following directory structure: FeatureA Feature is exactly what a feature is in our application (think Login feature, Search for hotel feature, etc.) as a class. Features are what the Services' controllers will serve, so our controllers will end up having only one line in our methods, hence, the thinnest controllers ever! Here's an example of generating a feature and serving it through a controller:
And we will have Inside the Feature class, there's a Now we need a controller to serve that feature: And our ViewsTo access a service's view file, prepend the file's name with the service name followed by two colons Example extending view file in blade: Usage with jobs is similar: new RespondWithViewJob('servicename::user.login')
RespondWithViewJob($template, $data = [], $status = 200, array $headers = []);Usage of template with data: $this->run(new RespondWithViewJob('servicename::user.list', ['users' => $users]));Or $this->run(RespondWithViewJob::class, [
'template' => 'servicename::user.list',
'data' => [
'users' => $users
],
]);JobA Job is responsible for one element of execution in the application, and play the role of a step in the accomplishment of a feature. They are the stewards of reusability in our code. Jobs live inside Domains, which requires them to be abstract, isolated and independent from any other job be it in the same domain or another - whatever the case, no Job should dispatch another Job. They can be ran by any Feature from any Service, and it is the only way of communication between services and domains. Example: Our
Each of these steps will have a job in its name, implementing only that step. They must be generated in their corresponding
domains that they implement the functionality of, i.e. our To generate a Job, use the Similar to Features, Jobs also implement the namespace App\Domains\User\Jobs;
use Lucid\Foundation\Job;
class SearchUsersByNameJob extends Job
{
private $query;
private $limit;
public function __construct($query, $limit = 25)
{
$this->query = $query;
$this->limit = $limit;
}
public function handle(User $user)
{
return $user->where('name', $this->query)->take($this->limit)->get();
}
}Now we need to run this and the rest of the steps we mentioned in public function handle(Request $request)
{
// validate input - if not valid the validator should
// throw an exception of InvalidArgumentException
$this->run(new ValidateUserSearchQueryJob($request->input()));
$results = $this->run(SearchUsersJob::class, [
'query' => $request->input('query'),
]);
if (empty($results)) {
$this->run(LogEmptySearchResultsJob::class, [
'date' => new DateTime(),
'query' => $request->query(),
]);
$response = $this->run(new RespondWithJsonErrorJob('No users found'));
} else {
// this job is queueable so it will automatically get queued
// and dispatched later.
$this->run(LogUserSearchJob::class, [
'date' => new DateTime(),
'query' => $request->input(),
'results' => $results->lists('id'), // only the ids of the results are required
]);
$response = $this->run(new RespondWithJsonJob($results));
}
return $response;
}As you can see, the sequence of steps is clearly readable with the least effort possible when following each A few things to note regarding the implementation above:
$this->run(LogUserSearchJob::class, [
'date' => new DateTime(),
'query' => $request->input(),
'resultIds' => $results->lists('id'), // only the ids of the results are required
]);class LogUserSearchJob
{
public function __construct($query, array $resultIds, DateTime $date)
{
// ...
}
}This will work perfectly fine, as long as the key name (
DataData is not really a component, more like a directory for all your data-related classes such as Models, Repositories, Value Objects and anything that has to do with data (algorithms etc.). FoundationThis is a place for foundational elements that act as the most abstract classes that do not belong in any of the
components, currently holds the Every service must be registered inside the foundation's service provider after being created for Laravel to know about it,
simply add // ...
use App\Services\Api\Providers\ApiServiceProvider;
// ...
public function register()
{
$this->app->register(ApiServiceProvider::class);
}Getting StartedThis project ships with the Lucid Console which provides an interactive user interface and a command line interface that are useful for scaffolding and exploring Services, Features, and Jobs. SetupThe For a list of all the commands that are available run Launching the Interactive Console (UI)
php artisan serve
1. Create a ServiceCLIUIUsing one of the methods above, a new service folder must've been created under The Api directory will initially contain the following directories: One more step is required for Laravel to recognize the service we just created. Register Service
2. Create a FeatureCLIUIUsing one of the methods above, the new Feature can be found at 3. Create a JobThis project ships with a couple of jobs that can be found in their corresponding domains under CLIUIUsing one of the methods above, the new Job can be found at public function handle()
{
return [
['name' => 'John Doe'],
['name' => 'Jane Doe'],
['name' => 'Tommy Atkins'],
];
}4. All TogetherBack to the Feature we generated earlier, add Run The JobIn ListUsersFeature::handle(Request $request) public function handle(Request $request)
{
$users = $this->run(GetUsersJob::class);
return $this->run(new RespondWithJsonJob($users));
}The Serve The FeatureTo be able to serve that Feature we need to create a route and a controller that does so. Generate a plain controller with the following command Add the class UserController extends Controller
{
public function get()
{
return $this->serve(ListUsersFeature::class);
}
}We just need to create a route that would delegate the request to our In Route::get('/users', 'UserController@get');Now if you visit MicroservicesIf you have been hearing about microservices lately, and wondering how that works and would like to plan your next project based on microservices, or build your application armed and ready for the shift when it occurs, Lucid is your best bet. It has been designed with scale at the core and the microservice transition in mind, it is no coincidence that the different parts of the application that will (most probably) later on become the different services with the microservice architecture are called Service. However, it is recommended that only when your monolith application grow so large that it becomes crucial to use microservices for the sake of the progression and maintenance of the project, to do the shift; because once you've built your application using Lucid, the transition to a microservice architecture will be logically simpler to plan and physically straight-forward to implement. There is a microservice counterpart to Lucid that you can check out here. With more on the means of transitioning from a monolith to a microservice. Event HooksLucid exposes event hooks that allow you to listen on each dispatched feature, operation or job. This is especially useful for tracing: use Illuminate\Support\Facades\Event;
use Lucid\Foundation\Events\FeatureStarted;
use Lucid\Foundation\Events\OperationStarted;
use Lucid\Foundation\Events\JobStarted;
Event::listen(FeatureStarted::class, function (FeatureStarted $event) {
// $event->name
// $event->arguments
});
Event::listen(OperationStarted::class, function (OperationStarted $event) {
// $event->name
// $event->arguments
});
Event::listen(JobStarted::class, function (JobStarted $event) {
// $event->name
// $event->arguments
});
全部评论
专题导读
上一篇：lucidarch/lucid: The Lucid Architecture for Scalable Laravel Applications.发布时间：2022-07-09下一篇：mpociot/laravel-apidoc-generator: Laravel API Documentation Generator发布时间：2022-07-09热门推荐
热门话题
 阅读排行榜
|
请发表评论