İş mantığını Saklı Prosedürde koymak veya kullanmamak?

"İş mantığını Saklı Prosedürde koymak veya kullanmamak?" Konulu üzerinde her zaman bir tartışma vardır. ORM Aracını kullanmamaya ve İş Mantığını Saklı Prosedürde koymamaya karar verirsek, İş Mantığını nereye koyarız?

Önceki uygulamalarımda, her zaman İş Mantığını yalnızca Saklı Prosedürlerde kullanmayı tercih ettim. Ardından .NET kodundan, Data Access Application Blocks'u kullanarak bu Saklı Prosedürleri çağırırım. SQLHelper vb. Ama bu her zaman senaryo olamaz. Bu yüzden biraz googling yaptım ama karışıklığa neden oldu .......

Herhangi bir öneriniz var mı?

Pragmatik bir yaklaşım benimsemektim - tarihsel olarak iş mantığını depolanan süreçlerde tutmanın temel 'yararı' performans nedenleriyle (2.5 kademe mimari), iş mantığını ise BLL katmanına (3 / N kademe) ayırmak genellikle bakım perspektifi ve test edilmesi daha kolay (Veri erişimini sahte / engelle).

Ancak, LINQ2SQL, EF ve NHibernate gibi LINQ etkin .NET ORMS'lerinin şimdi, sorgu planlarının önbelleğe alınabileceği parametreli SQL sorguları oluşturduğu göz önüne alındığında, SQL Injection vb. her zamankinden daha çekici ve SPROC'ların çoğundan (özellikle sorgu merkezli olanlar) tamamen kaçınılabilir. .NET'teki depo desenleri genel olarak IQueryable / accept Expression ağacı parametrelerini gösterir ve bu sayede tablolarınıza güvenli, ancak esnek bir erişim sağlar. (Şahsen SOA tipi mimarilerde, IQueryable’e BLL’nin ötesinde maruz kalmam, yani Hizmet ve Sunum katmanlarınız iyi tanımlanmış yöntemlerle çalışmalıdır. Aksi halde sisteminizi asla tam olarak test edemezsiniz ve kazanırsınız '

Bununla birlikte, iyi bir büyüklükte bir sistemde, performans nedenleriyle gerçekten veri yoğun bir kod parçasının yine de Stored Proc olarak yazılması gerekebilecek birkaç istisna olacaktır. Bu gibi durumlarda, SPROC’yi koruyacağım ve SPROC’yi ORM aracılığıyla göstereceğim, ancak yine de işlevi BLL’nizde bir geçiş yöntemi olarak göstereceğim.

Bir java geliştiricisi olmak, tercihim BLL'ye iş mantığı koymaktı (hoş ve kolay kaynak kontrolü, tanıdıklık vb. Vb.).

Bununla birlikte, farklı teknolojiler kullanan birçok dağıtılmış uygulamaya sahip (C #, Java, Pick (sorma)) büyük bir işletme için çalıştıktan sonra, saklı yordamları kullanmanın önemli bir yararı ortaya çıktı:

Saklı yordamlar farklı uygulamalar arasında paylaşılabilir .

Ekibimizin burada yumuşak bir kuralı var. Bazen Business Logic'i T-SQL'de çözmek daha iyidir, bazen c # (Business Layer) ile yapmak daha kolaydır.

Bu yüzden pragmatik bir çözümümüz var: Daha iyi uyan bir yere koyun. Teorinin bazen çok katı olduğunu biliyorum ... ama bu teori :-)

Her ikisinin de avantajları ve dezavantajları vardır (bence):

Bir tür SQL kaynak kontrolü kullanmıyorsanız (birçok yerde kullanmayan) ve üzerinde çalışan birden fazla geliştiriciniz varsa, saklı yordamlar kabus olabilir. Birisi saklı bir prosedürü değiştirebilir ve bu prosedürü çağıran kodu güncellemeyi unutabilir ve bunu bilmeden önce işlenmeyen istisnalar atacak bir site oluşturup dağıttığınızı unutmayın (parametre sayısı uyuşmazlığı vb.).

Öte yandan, saklı yordamlar, belirli durumlarda daha hızlı hata düzeltmelerini sağlar. Saklı yordamda bir hata varsa, onu düzeltmeniz yeterlidir. ORM'deki bir hata düzeltmesi yeniden oluşturulmasını gerektirir. Yapım sürecinize bağlı olarak bu uzun / can sıkıcı olabilir.

İş Mantığımızı daima İş Mantığı Katmanına koyarız. Saklı Prosedür'e koyarsanız, RDBMS'nizi değiştirdikten sonra kaybolacaktır.

"İş mantığı" biraz belirsiz bir terimdir. Demek istediğim, tek bir tanımı yok. Bir kural, mümkün olduğunda katmanlar arasındaki iletişimi en aza indirmektir. Bu nedenle, bir satır eklemeden önce kontrol etmek için sunucuya boş müşteri adı göndermenize gerek yoktur.

Bir kuralın okuma veritabanına dayanması durumunda durumlar vardır. Hesap 1'den Hesap 2'ye para aktarmak istediğinizi söyleyin. Her iki hesabı da okumanız, iyi durumda olduklarından ve Hesap 1'deki tutarın yeterli olduğundan emin olmanız gerekir. Bu durumda, sunucu bu kural için daha iyi bir adaydır, çünkü müşterinin (burada BL olan) bu işlem için veri tabanı katmanına 3 çağrı yapması gerekmez.

Tabiki, çözümünüzün veri tabanından bağımsız olması gerekiyorsa, yalnızca CRUD için saklanan işlemleri yapın (eğer kullanılıyorsa).

Mantık her zaman BLL'de olmalıdır, çünkü:

• Düzgün test edilebilir
• SQL 20XX eski hale geldiğinde ve en son sürüme geçmeniz gerektiğinde, kodunuzu yeniden yazmak zorunda değilsiniz.
• İnsanlar anında değişiklik yapma eğiliminde değiller (SP'lerin argümanı olarak öne sürüldüler)
• SP'ler benim tecrübelerime göre, özellikle birkaç nesil bakım / değişiklikten sonra, en büyük geliştirici hatasının noktasıdır.

Bir SP'nin X satırından daha uzun sürmesinden sonra, amaçlandığı gibi çalışmadığını belirten bir yasa olması gerektiğine inanıyorum.

Seçilen dilde uygulanan tüm iş mantığımızı içeren bir hizmet katmanı yaratır ve veritabanını yalnızca sorgular için kullanırız. Bu yaklaşım bizim tarafımızdan zorunludur, çünkü amacımız çeşitli veritabanı uygulamaları olan uygulamalar sunmak için COTS çözümleri oluşturmaktır. Hazırda Bekletme bu durumlarda bizim için bir cankurtaran olduğunu kanıtladı.

Veritabanının taşınabilirliği dışında, bu yaklaşımın en büyük avantajının, tüm cevaplarınızı tek bir aramada bulabilmeniz olduğunu düşünüyorum.

Ayrıca, bir foruma verilen cevapların bir kısmına rağmen, şirket için tercih edilen veri tabanı değiştiği için üç yılda 2 veri tabanı dönüşümü yapan bir servet 100 sigorta şirketi için çalışan bir arkadaşım var.

Sınırlı deneyimimde, saklı yordamlar ve diğer veritabanı özellikleriyle veri bütünlüğünü korumayı tercih ediyorum. Örneğin, iki hesap arasında para transferi gerçekleştiriyor olsaydım, saklı bir prosedür yazardım. Birden fazla uygulama dilini kullanabilmek için değerli buluyorum.