Eloquent સાથે ઉપયોગી ભંડાર?

ગયા અઠવાડિયે મેં લખ્યું હતું Eloquent એન્ટિટી માટે રીપોઝીટરી ટેમ્પ્લેટની નકામીતા વિશેનો લેખ, જો કે, તેણે મને તેના ફાયદા માટે આંશિક રીતે તેનો ઉપયોગ કેવી રીતે કરવો તે જણાવવાનું વચન આપ્યું હતું. આ કરવા માટે, હું વિશ્લેષણ કરવાનો પ્રયાસ કરીશ કે આ નમૂનાનો સામાન્ય રીતે પ્રોજેક્ટ્સમાં કેવી રીતે ઉપયોગ થાય છે. રિપોઝીટરી માટે પદ્ધતિઓનો ન્યૂનતમ જરૂરી સમૂહ:

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);
}

જો કે, વાસ્તવિક પ્રોજેક્ટ્સમાં, જો રિપોઝીટરીઝનો ઉપયોગ કરવાનું નક્કી કરવામાં આવ્યું હોય, તો રેકોર્ડ્સ પુનઃપ્રાપ્ત કરવાની પદ્ધતિઓ ઘણીવાર તેમાં ઉમેરવામાં આવે છે:

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);

    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

આ પદ્ધતિઓ ઇલોક્વન્ટ સ્કોપ્સ દ્વારા અમલમાં મૂકી શકાય છે, પરંતુ પોતાને લાવવાની જવાબદારી સાથે એન્ટિટી વર્ગોને ઓવરલોડ કરવું એ શ્રેષ્ઠ વિચાર નથી, અને આ જવાબદારીને રિપોઝીટરી વર્ગોમાં ખસેડવું તાર્કિક લાગે છે. એવું છે ને? મેં ખાસ કરીને આ ઈન્ટરફેસને બે ભાગમાં વિભાજિત કર્યું છે. પદ્ધતિઓનો પ્રથમ ભાગ લેખન કામગીરીમાં ઉપયોગમાં લેવાશે.

પ્રમાણભૂત લેખન કામગીરી છે:

• નવી વસ્તુ અને પડકારનું નિર્માણ PostRepository::save
• PostRepository::getById, એન્ટિટી મેનીપ્યુલેશન અને સમન્સિંગ PostRepository::save
• એક પડકાર PostRepository::delete

લખવાની કામગીરી આનયન પદ્ધતિઓનો ઉપયોગ કરતી નથી. રીડ ઑપરેશનમાં, માત્ર get* પદ્ધતિઓનો ઉપયોગ થાય છે. જો તમે વિશે વાંચો ઇન્ટરફેસ સેગ્રિગેશન સિદ્ધાંત (પત્ર I в સોલિડ), પછી તે સ્પષ્ટ થશે કે અમારું ઇન્ટરફેસ ખૂબ મોટું છે અને ઓછામાં ઓછી બે અલગ અલગ જવાબદારીઓ કરે છે. તેને બે વડે વિભાજીત કરવાનો સમય આવી ગયો છે. પદ્ધતિ getById બંનેમાં જરૂરી છે, પરંતુ જેમ જેમ એપ્લિકેશન વધુ જટિલ બનતી જશે તેમ તેમ તેના અમલીકરણમાં તફાવત આવશે. આ આપણે થોડી વાર પછી જોઈશું. મેં અગાઉના લેખમાં લેખન ભાગની નકામીતા વિશે લખ્યું હતું, તેથી આ એકમાં હું તેના વિશે ભૂલી જઈશ.

વાંચો ભાગ મને એટલો નકામો લાગે છે, કારણ કે Eloquent માટે પણ અહીં ઘણા અમલીકરણો હોઈ શકે છે. વર્ગને શું નામ આપવું? કરી શકે છે ReadPostRepository, પરંતુ નમૂના માટે રીપોઝીટરી તેની પાસે પહેલેથી જ ઓછી સુસંગતતા છે. તમે માત્ર કરી શકો છો પોસ્ટક્વેરીઝ:

<?php
interface PostQueries
{
    public function getById($id): Post;
    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

Eloquent સાથે તેનો અમલ કરવો એકદમ સરળ છે:

<?php
final class EloquentPostQueries implements PostQueries
{
    public function getById($id): Post
    {
        return Post::findOrFail($id);
    }

    /**
    * @return Post[] | Collection
    */
    public function getLastPosts()
    {
        return Post::orderBy('created_at', 'desc')
            ->limit(/*some limit*/)
            ->get();
    }
    /**
    * @return Post[] | Collection
    */
    public function getTopPosts()
    {
        return Post::orderBy('rating', 'desc')
            ->limit(/*some limit*/)
            ->get();
    }

    /**
    * @param int $userId
    * @return Post[] | Collection
    */
    public function getUserPosts($userId)
    {
        return Post::whereUserId($userId)
            ->orderBy('created_at', 'desc')
            ->get();
    }
}

ઇન્ટરફેસ અમલીકરણ સાથે સંકળાયેલું હોવું જોઈએ, ઉદાહરણ તરીકે માં AppServiceProvider:

<?php
final class AppServiceProvider extends ServiceProvider 
{
    public function register()
    {
        $this->app->bind(PostQueries::class, 
            EloquentPostQueries::class);
    }
}

આ વર્ગ પહેલેથી જ ઉપયોગી છે. તે નિયંત્રકો અથવા એન્ટિટી વર્ગને રાહત આપીને તેની જવાબદારીનો અહેસાસ કરે છે. નિયંત્રકમાં તેનો ઉપયોગ આ રીતે કરી શકાય છે:

<?php
final class PostsController extends Controller
{
    public function lastPosts(PostQueries $postQueries)
    {
        return view('posts.last', [
            'posts' => $postQueries->getLastPosts(),
        ]);
    }
} 

પદ્ધતિ પોસ્ટ કંટ્રોલર::લાસ્ટ પોસ્ટ્સ માત્ર કેટલાક અમલીકરણ માટે પૂછે છે પોસ્ટસક્વેરીઝ અને તેની સાથે કામ કરે છે. અમે લિંક કરેલ પ્રદાતામાં પોસ્ટક્વેરીઝ વર્ગ સાથે EloquentPostQuerys અને આ વર્ગને નિયંત્રકમાં બદલવામાં આવશે.

ચાલો કલ્પના કરીએ કે અમારી એપ્લિકેશન ખૂબ જ લોકપ્રિય બની છે. પ્રતિ મિનિટ હજારો વપરાશકર્તાઓ નવીનતમ પ્રકાશનો સાથે પૃષ્ઠ ખોલે છે. સૌથી વધુ લોકપ્રિય પ્રકાશનો પણ ઘણી વાર વાંચવામાં આવે છે. ડેટાબેઝ આવા લોડને ખૂબ જ સારી રીતે હેન્ડલ કરતા નથી, તેથી તેઓ પ્રમાણભૂત સોલ્યુશનનો ઉપયોગ કરે છે - એક કેશ. ડેટાબેઝ ઉપરાંત, ચોક્કસ ડેટા સ્નેપશોટ ચોક્કસ કામગીરી માટે ઑપ્ટિમાઇઝ કરેલ સ્ટોરેજમાં સંગ્રહિત થાય છે - memcached અથવા વારંવાર.

કેશીંગ લોજિક સામાન્ય રીતે એટલું જટિલ હોતું નથી, પરંતુ EloquentPostQueries માં તેને અમલમાં મૂકવું ખૂબ જ યોગ્ય નથી (જો માત્ર કારણ કે એક જવાબદારી સિદ્ધાંત). નમૂનાનો ઉપયોગ કરવો વધુ સ્વાભાવિક છે ડેકોરેટર અને મુખ્ય ક્રિયા માટે સુશોભન તરીકે કેશીંગનો અમલ કરો:

<?php
use IlluminateContractsCacheRepository;

final class CachedPostQueries implements PostQueries
{
    const LASTS_DURATION = 10;

    /** @var PostQueries */
    private $base;

    /** @var Repository */
    private $cache;

    public function __construct(
        PostQueries $base, Repository $cache) 
    {
        $this->base = $base;
        $this->cache = $cache;
    }

    /**
    * @return Post[] | Collection
    */
    public function getLastPosts()
    {
        return $this->cache->remember('last_posts', 
            self::LASTS_DURATION, 
            function(){
                return $this->base->getLastPosts();
            });
    }

    // другие методы практически такие же
}

ઈન્ટરફેસ અવગણો રીપોઝીટરી કન્સ્ટ્રક્ટરમાં. કેટલાક અજ્ઞાત કારણોસર, તેઓએ લારાવેલમાં કેશીંગ માટેના ઇન્ટરફેસને આ રીતે નામ આપવાનું નક્કી કર્યું.

Класс CachedPostQuerys માત્ર કેશીંગનો અમલ કરે છે. $this->cache->યાદ રાખો આ એન્ટ્રી કેશમાં છે કે કેમ તે તપાસે છે અને જો નહીં, તો કોલબેકને કૉલ કરે છે અને કેશમાં પરત કરેલ મૂલ્ય લખે છે. આ વર્ગને એપ્લિકેશનમાં અમલમાં મૂકવાનું બાકી છે. અમને બધા વર્ગોની જરૂર છે જે એપ્લિકેશનમાં ઇન્ટરફેસના અમલીકરણની વિનંતી કરવા માટે છે પોસ્ટક્વેરીઝ વર્ગનો દાખલો મળવા લાગ્યો CachedPostQuerys. જો કે, તેણે પોતે CachedPostQuerys કન્સ્ટ્રક્ટરને પરિમાણ તરીકે વર્ગ પ્રાપ્ત થવો જોઈએ EloquentPostQuerysકારણ કે તે "વાસ્તવિક" અમલીકરણ વિના કામ કરી શકતું નથી. અમે બદલીએ છીએ AppServiceProvider:

<?php
final class AppServiceProvider extends ServiceProvider 
{
    public function register()
    {
        $this->app->bind(PostQueries::class, 
            CachedPostQueries::class);

        $this->app->when(CachedPostQueries::class)
            ->needs(PostQueries::class)
            ->give(EloquentPostQueries::class);
    }
}

મારી બધી ઇચ્છાઓ પ્રદાતામાં તદ્દન સ્વાભાવિક રીતે વર્ણવવામાં આવી છે. આમ, અમે ફક્ત એક વર્ગ લખીને અને કન્ટેનર રૂપરેખાંકન બદલીને અમારી વિનંતીઓ માટે કેશીંગનો અમલ કર્યો. બાકીનો એપ્લિકેશન કોડ બદલાયો નથી.

અલબત્ત, કેશીંગનો સંપૂર્ણ અમલ કરવા માટે, અમાન્યતાનો અમલ કરવો પણ જરૂરી છે જેથી કાઢી નાખેલ લેખ અમુક સમય માટે સાઇટ પર અટકી ન જાય, પરંતુ તરત જ કાઢી નાખવામાં આવે. પરંતુ આ નાની બાબતો છે.

બોટમ લાઇન: અમે એક નહીં, પરંતુ બે ટેમ્પલેટનો ઉપયોગ કર્યો છે. નમૂના કમાન્ડ ક્વેરી રિસ્પોન્સિબિલિટી સેગ્રિગેશન (CQRS) ઇન્ટરફેસ સ્તરે વાંચવા અને લખવાની કામગીરીને સંપૂર્ણપણે અલગ કરવાની દરખાસ્ત કરે છે. દ્વારા હું તેની પાસે આવ્યો ઇન્ટરફેસ સેગ્રિગેશન સિદ્ધાંત, જે સૂચવે છે કે હું કુશળ રીતે પેટર્ન અને સિદ્ધાંતોની હેરફેર કરું છું અને પ્રમેય તરીકે એક બીજામાંથી મેળવું છું :) અલબત્ત, દરેક પ્રોજેક્ટને એન્ટિટી પસંદ કરવા માટે આવા અમૂર્તની જરૂર નથી, પરંતુ હું તમારી સાથે યુક્તિ શેર કરીશ. એપ્લિકેશનના પ્રારંભિક તબક્કે વિકાસ, તમે ખાલી વર્ગ બનાવી શકો છો પોસ્ટક્વેરીઝ Eloquent દ્વારા સામાન્ય અમલીકરણ સાથે:

<?php
final class PostQueries
{
    public function getById($id): Post
    {
        return Post::findOrFail($id);
    }

    // другие методы
}

જ્યારે કેશીંગની જરૂરિયાત ઊભી થાય, ત્યારે એક સરળ ચાલ સાથે તમે આ વર્ગની જગ્યાએ ઇન્ટરફેસ (અથવા અમૂર્ત વર્ગ) બનાવી શકો છો. પોસ્ટક્વેરીઝ, વર્ગમાં તેના અમલીકરણની નકલ કરો EloquentPostQuerys અને મેં અગાઉ વર્ણવેલ સ્કીમ પર જાઓ. બાકીનો એપ્લિકેશન કોડ બદલવાની જરૂર નથી.

વર્ગો, ઇન્ટરફેસ સાથે આ બધી યુક્તિઓ, નિર્ભરતા ઇન્જેક્શન и CQRS માં વિગતવાર વર્ણવેલ છે મારું પુસ્તક "કોમ્પ્લેક્સ વેબ એપ્લિકેશનનું આર્કિટેક્ચર". આ કોયડાનો ઉકેલ પણ છે કે શા માટે આ લેખ માટેના ઉદાહરણોમાં મારા તમામ વર્ગોને અંતિમ તરીકે ચિહ્નિત કરવામાં આવ્યા છે.

સોર્સ: www.habr.com