Menghubungkan Lapisan Bisnis dan Repositori menggunakan Pola Satuan Kerja

Pertanyaan saya mirip dengan yang ini di Stack Overflow: Apa cara yang benar untuk menggunakan Unit Kerja / Repositori di dalam lapisan bisnis?

Skenario:

Solusi .Net
IRepository digunakan untuk mengambil objek dari DB
IUnitOfWork digunakan untuk memungkinkan transaksi di beberapa repositori

Ini masuk akal bagi saya dan saya telah menerapkan sesuatu di sepanjang garis ini yang berfungsi dengan baik. Sekarang saya ingin memperkenalkan lapisan logika bisnis dan saya mengalami kesulitan mengatur tiga elemen (BLL, UnitOfWork dan Repository) dalam pikiran saya.

Pemahaman saya:

Repositori - pengambilan data, manipulasi
UnitOfWork - kegigihan
BLL - logika yang relevan dengan bisnis ('dunia nyata') (tidak suka istilah itu!)

Pertimbangkan kami memiliki ujung depan ASP.Net MVC.

Seperti apa bentuk BLL dan seperti apa pengontrol MVC yang menggunakannya?

Untuk referensi: Saya bertanya-tanya apakah mungkin implementasi IUnitOfWork / IRepository saya mungkin menjadi penyebab kebingungan saya.

public class IRepository<T> 
{
    private IObjectSet<T> objSet;
    public IRepository<T>(IUnitOfWork uow)
    {
        objSet = uow.CreateObjectSet<T>();
    }

    public IQueryable<T> Add(T entity)
    {
        objSet.Add(entity);
    }
    //etc. etc. for delete, attach, getall
}

Jadi saya merasa seperti memiliki BLL, saya harus mengirimkannya ke IUnitOfWork, sehingga dapat menggunakannya untuk membuat instance IRepository yang diperlukan. Tetapi bagaimana BLL (memisahkan DLL dari ujung depan) 'tahu' implementasi IRepository apa yang akan dibangun?

— glosrob
sumber

Saya benar-benar berpikir pertanyaan Anda baik-baik saja. Masalahnya adalah, ini adalah area fuzzy; tidak ada One True Way ™ untuk melakukannya, dan tidak ada yang mau memberi Anda saran karena mereka tidak ingin diberi tahu bahwa mereka Melakukannya Salah ™. Saya pribadi lebih suka pendekatan database-centric lebih tipis, lebih banyak pada proyek-proyek kecil; semua upacara ini benar-benar dimaksudkan untuk aplikasi perusahaan berskala besar.

— Robert Harvey

Poin yang adil baik dan kesalahan adalah dengan kata-kata saya. Saya tertarik pada pendapat pribadi yaitu 'ini adalah bagaimana saya pribadi akan mendekatinya'.

— glosrob

Harap perhatikan bahwa saya hanya memiliki pengalaman kecil dengan .NET framework dan bahwa jawaban ini hanya terkait dengan bagian arsitektur dari pertanyaan Anda.

Sejauh yang saya mengerti, Anda pada dasarnya menerapkan pola arsitektur berikut dalam aplikasi Anda:

Layers: Tampaknya Anda memiliki lapisan persistensi (Pola Repositori), lapisan logika bisnis, dan lapisan tampilan.

Model-View-Controller: Pola ini diterapkan di lapisan tampilan menggunakan ASP.NET MVC.

Saya kira pertanyaannya adalah: seperti apa tampilan BLL dan seperti apa pengontrol MVC yang menggunakannya?

Pertama-tama, arsitektur ini ditujukan untuk aplikasi perusahaan berskala besar seperti yang disebutkan oleh Robert Harvey dalam komentarnya untuk pertanyaan Anda. Apa karakteristik untuk sistem tersebut adalah bahwa logika domain (yang Anda enkapsulasi dalam lapisan logika bisnis) harus dapat diakses melalui berbagai antarmuka.

Pertimbangkan Twitter misalnya - Twitter dapat memiliki lapisan logika bisnis yang menyediakan layanan untuk mendaftarkan dan memvalidasi pengguna, memposting tweet, dan banyak lagi. Di atas lapisan logika bisnis ini, beberapa komponen lain bisa ada di lapisan tampilan, misalnya antarmuka web dan komponen layanan web. Karena semua logika bisnis dirangkum dalam lapisan logika bisnis, Anda dapat mengikuti prinsip KERING dan meningkatkan rawatan dan atribut kualitas lainnya.

Untuk kembali ke pertanyaan Anda - Anda harus merangkum logika bisnis dan akses data di BLL. Pengontrol (pikirkan MVC) harus menggunakan BLL dan tidak boleh memiliki akses langsung ke database. Pertimbangkan layer tampilan sebagai antarmuka ke aplikasi Anda.

Jadi saya merasa seperti memiliki BLL, saya harus mengirimkannya ke IUnitOfWork, sehingga dapat menggunakannya untuk membuat instance IRepository yang diperlukan. Tetapi bagaimana BLL (memisahkan DLL dari ujung depan) 'tahu' implementasi IRepository apa yang akan dibangun?

BLL harus tahu repositori (sumber data?) Mana yang digunakannya. Lapisan di atas seharusnya tidak mengontrol ini. Sekali lagi, pertimbangkan layer tampilan hanya sebagai antarmuka ke logika bisnis Anda.

Jika Anda tidak memerlukan overhead dari lapisan logika bisnis, Anda juga dapat memilih untuk menggunakannya hanya untuk akses data dalam bentuk objek akses data .

Saya harap ini membantu memperjelas tanggung jawab berbagai komponen.

— BenR
sumber