• Oct
  • 01
  • 2014

Prensip sahibi yazılımlar VOL. II

Tags: , | View: 39 | Comments:

Yazılım geliştirirken karşılaştığımız problemler ya da karşılamamız gereken ihtiyaçlar ne kadar farklı olsada, bir noktada bu problem ve ihtiyaçlara bakış açısı ortak hale geliyor. Belli kalite özelliklerini korumak ve katma değer katan çözümler oluşturabilmek için bu ortak nokta da prensipler ile karşılaşıyoruz. Bir kaç önceki yazımda ortaya atılan bu prensiplerden bahsetmeye başlamıştım. Şimdi bir kaç tanesinden daha bahsetmek istiyorum.

DRY – Don’t Repeat Yourself

Geliştirdiğimiz yazılımlarda, -hatta biraz daha derine girim; sınıflarda/metodlarda asıl katma değeri oluştururuz. Yani temelinde, bir metod içerisindeki yazdığımız algoritma ya da oluşturduğumuz obje modeli karşılamamız gereken ihtiyacın ya da çözülmesi gereken problemin cevabıdır. Çözmeye çalıştığımız problemler büyüdükçe ve karmaşık hale geldikçe, daha önce kullanmış olduğumuz cevapları tekrar kullanmaya başlarız. Bu noktada DRY prensibi dur der. Kendini tekrarlama diye karşımıza çıkar.

Geliştirdiğimiz yazılımlarda, çözüm olarak oluşturduğumuz yapıların yazılım içerisinde tek bir tane olması gereklidir.  Bunun önüne geçemezsek, bir problem için, aynı çözümün birden fazla versiyonu kodun içerisinde kendine yer bulur… Gelişir, gelişir, büyür ve kodun bakımını zorlaştırır. E-mail validasyonu yapan bir yapı ile aynı validasyonun daha farklı bir string operasyonu ile yapılıyor olması, yazılım içinde de tutarsızlığa yol açar. Sonra uğraş dur…

Kod yazarken, daha önce benzer bir çözüme benzediğini düşüyorsanız, o çözümü re-use edilebilecek hale getirmek en uygunu olacaktır.  DRY prensibini uygulamak için code-generation araçları ve kod dökümantasyonu oluşturan araçlardan faydalanmak kolaylık sağlayacaktır. Referans kitabı olarak arasıra danıştığım, David Thomas-Andrew Hunt ikilisinin yazdığı, The Pragmatic Programmer kitabını DRY prensibi ile ilgili olarak şiddetle tavsiye ederim. Uygulanabilirliği konusunda güzel ip uçları içermekte.

SoC – Seperation Of Concerns

separation of concernsSoC, yazılımdaki elemanların kendilerine özel olmasını, sorumluluklarının kendilerine ait olup, başka elemanlar ile paylaşmamasını söyler. Sorumlulukların ayrı olmasının gerekliliği bu prensibin altını çizdiği temel noktadır.  Yazılımı geliştirirken, “sınır” diyebileceğimiz kavramlar bu sorumlulukları bir birinden ayıran en net ifadeler olabilir. En basitinden, layer ve tier kavramları ile belli sorumlulukları bir birinden ayırırız. Birazcık daha içeri girersek, yazılım bileşenlerimizin namespace’leri de, sorumlulukları ayırmak için kullanabileceğimiz sınırlardır diyebiliriz.

Genelde bu sorumlulukları belirlerken, çok küçük parçalara kadar inmeye çalışırız. Çok küçük parçalardan daha önemli olan sorumluluk kümelerinin net ve ayrı olabilmesidir. Einstein’nın bir lafı vardır çok hoşuma giden,  “Make everything as simple as possible, but not simpler.” Her şeyi basit yap ama daha basit yapma…Benzer şekilde sorumlulukları küçük parçalara ayır ama daha da küçültme şeklinde bu konu için yorumlayabilirim. Sorumluluk kümelerini iyi oluşturamazsak, ayrık ayrık bir sürü parça sistemde kaybolur gider. Bu da çok iyi bir şey değil.

Yazılım içindeki bileşenlerin bir birine bağlılık derecesi(coupling) ve bileşenler içerisindeki sorumluluk ilişksi(cohesion), SoC prensibi için önemli iki kavramdır. Bileşenlerin bağlılık derecesinin düşük olması ve bir bileşen içindeki sorumluluk ilişkisinin yüksek olması her zaman tercih edilmelidir. Yani low-coupling, high-cohesion olmazsa olmaz… Bu sayede bağlılık derecesi düşük olursa, sorumlulukar bileşen başına dağılmış olacağından yazılımın kontrolü bizim elimizde daha kolay olacaktır.  Bileşenler içerisindeki sorumluluklarında bir birlerine yakın olması, re-usebility’i ortaya çıkaracaktır.

SoC prensibi, geliştirdiğimiz yazılımları genişletebilir yapabilmenin de en önemli noktasıdır. Sorumlulukları ve bağlılıkları iyi ayırabilmeyi söylediğinden dolayı, yazılımlarımızın esnek ve genişleyebilecek alt yapıda olmasına ön ayak olur.

Bu iki önemli prensip de yazılım geliştirmede oldukça önemli konuların altını çiziyor. Pratik olarak zaman zaman dikkat etmesi zor olsa da, gerçekleştirildiği takdirde oldukça faydalı sonuç vereceklerdir.

  • Oct
  • 01
  • 2014

18 Ekim, Yazılım Teknolojileri Seminerleri…

Tags: | View: 66 | Comments:

18 Ekim Cumartesi günü, İstanbul Şehir Üniversitesi‘nde düzenlenecek olan, artık geleneksel hale gelen, NedirTV?com’un bir etkinliği mevcut. Yazılım ve yazılım sektörü ile ilgili çeşitli konuların deneyimli ve tanıdık simalar tarafından paylaşılacağı bu mütevazi ve sıcak etkinliği kaçırmamanızı tavsiye ederim. Benim de Microservices ile ilgili sesli düşüneceğim bir sunumum olacak. Fırsat yaratıp da uzun süredir göremediğim arkadaşları da bu vesile ile görecek olmak benim için ayrı bir motivasyon. :)

Etkinlik programı ve ayrıntıları aşağıdaki gibi; katılmak için bu adresteki kayıt formunu doldurmanız gerekmekte.

18EkimNedirtv.com‘un düzenlediği Yazılım Teknolojileri Seminerleri yazılım dünyasının deneyimli konuşmacılarını bir araya getiren yazılım ve bilişim teknolojileri etkinliğidir. Arda Çetinkaya, Burak Selim Şenyurt, Ercan Bozkurt, Muhammed Cuma Tahiroğlu ve Nezih Tınas‘ın etkinlik boyunca yapacağı beş farklı sunuma katılmak için etkinlik.com.tr üzerindeki kayıt formunu doldurmanız yeterlidir.

Etkinlik programı
10:00 Kurumsal Uygulamaları(Enterprise Applications) Tanıyalım – Burak Selim Şenyurt
11:10 Bir “Canlı Ön Analiz” Toplantısı – Nezih Tınas
12:20 Ara
13:00 Microservices – Arda Çetinkaya
14:10 Fonksiyonel Paradigma – Muhammed Cuma Tahiroğlu
15:30 Sanal Gerçeklik – Ercan Bozkurt

Sunumlar boyunca sponsorlarımızın ilettiği sürpriz hediyelerimiz olacaktır.

Etkinlik Sponsorları
Microsoft Türkiye
Dikeyeksen Yayıncılık
Kariyer Mimarı
Portya

Destekleyenler
İstanbul Şehir Üniversitesi Kuluçka Merkezi

 

Bu etkinliğin gerçekleşmesini sağlayan ve bana da yer veren NedirTV?com‘a ve Uğur Umutluoğlu‘na buradan tekrar teşekkür ederim. Etkinlikte görüşmek üzere.

  • Sep
  • 29
  • 2014

“Test” yazamıyoruz, çünkü test edilebilir kod yazmıyoruz…

Tags: , , | View: 378 | Comments:

Test kavramı bir yazılım için olmazsa olmaz. Sanırım artık bu herkesin kabul ettiği bir şey. Yazılımın çalıştığını kanıtlamak, ihtiyaçları karşıladığını göstermek ve belli kalite özelliklerinin sağlandığını doğrulamak için en somut çalışmalardan biri. Çeşitli test adımları, test türleri ve test süreçlerinden çok yazılımcı olarak, geliştirme aşamasında yapmadığımız testlerden bahsetmeye çalışacağım. Neden yapmadığımızın sebebini bulabiliriz belki…

Neden “test” yazmıyoruz?

Bir çok sebep sayabiliriz sanırım. “Zaman bulamıyorum”, “Gerek duymuyorum”, “Test benim işim değil ki”, “Test kodu yazacağıma, 10 tane ekstra özellik yazarım” falan gibi çeşitli sebepler sanırım çoğu kişinin ortak cevabı olacaktır. Biraz acı olacak belki ama ne yazık ki bunlar bahaneden başka hiç bir şey değil. Hiç biri geçerli bir sebep değil. Test yazmıyor olmamızın en büyük sebebi, aslında kendimiziz. Test

Yazdığımız kodların, test edilebilir olmaması test yazmıyor olmamızın en büyük sebebi. Test edilebilir kod yazmak, test yazmaktan çok daha zor bir olay ne yazık ki. Test yazmak isteyip de bu gerçekle karşılaştığımız zaman, motivasyonun kaybolması ve test yazmayı bırakmak en çok duyduğum ve bizzat da yaşadığım bir olay. Test edilebilir kod yazmak, belli bir zaman geçtikten sonra bazı konulara hakim olduktan sonra daha kolay olacaktır. Bu noktada herkes biraz öz eleştiri yaparsa benzer şeyleri düşüneceğine inanıyorum. Test edilebilir kod yazmak, çeşitli yazılım geliştirme prensiplerine hakim oldukça daha kolaylaşacaktır. Yazdığınız kodlar için birim test yazmaya başladığınızda bir noktada tıkanıyorsanız, yılmadan neden yazamadığınız, kodun neresinde tıkandığınız konusunda düşünmeye başlayın. Daha sonra problem ile ilgili olabilecek prensipleri(mesela OOP prensipleri yani SOLID ya da diğer prensipleri; YAGNI,KISS….vs.), kodunuzda doğrulamaya çalışın. Bu şekilde hem kodunuzu iyileştirmiş, hem de test edilebilir bir koda sahip olmuş olacaksınız. Zamanla bu bir alışkanlık haline geleceğinden, yazdığınız kod için birim test yazmak çok daha kolay olacaktır. Yazdığınız kodlara, test yazabiliyor olmak, programınızın çalışabilirliğini doğrulamak dışında, tasarımınızı da doğru bir şekilde refactor etmenizin en etkili yöntemi olacaktır ayrıca.

TDD

Test yazmak, farklı bir düşünce yaklaşımı da gerektirdiğinden, normal bir kodla, test kodu yazmak farklılık gösterecektir. Genelde metod yazarken, ilk olarak “doğru” sonuç odaklı bir yöntem izleriz. Çünkü, “doğru”yu zaten biliyor oluruz ve bu genelde kolay gelir. MusteriGetir() diye, belli bir parametre aldığında müşteri bilgilerini getiren metodu yazarken, getirilen müşterilerin aktif/pasif durumu, geçerli bölgesi, alışveriş durumları vs. gibi kontrol edilmesi gereken arka plandaki ihtiyaçlar sonradan kodumuzda yer bulur. Hele bu ihtiyaçlar net değilse, en basit kontrol durumları bile atlanır. Olmaz demeyin, oluyor… Ancak ilk olarak “doğru” sonuçlara odaklanmak yerine, olabilecek diğer ihtimalleri de kontrol edebilecek bir şekilde kodumuzu tasarlarsak, test edebileceğimiz kapıları kendiliğinden açmış olacağız. Daha sonra test yazmak zaten kolay olacaktır. Çünkü kapılar bize neleri test etmemiz gerektiğini gösterecektir. Bu noktada TDD(Test Driven Development)’ın altını çizmek isterim. Benim çok tercih ettiğim bir yaklaşım olmasa da belki size kolaylık sağlar. TDD ve test yazmanın farklı şeyler olduğunun da ayrıca özellikle altını çizmek isterim. TDD, birim testlerinizi önce yazarak kodu geliştirme yönünde sizi motive eden bir geliştirme yöntemidir. Bunun dışında, test yazmak, birim test geliştirmek, geliştirmelerinizi tamamladıktan sonra da yapabileceğiniz bir aktivite olduğundan TDD’den farklı olarak yorumlanmalıdır. TDD’nin, test edilebilir kod yazma konusunda etkili olduğuna inanıyorum ama daha yazmadığınız bir şeyi test ederek ortaya çıkarmak, yukarıda bahsetmiş olduğum tasarımı etkili refactor etme konusunda engel olarak karşınıza çıkabilir. En azından benim çıkıyor. Belki daha yeterince oturmamıştır bazı şeyler, kim bilir… Bu konu biraz karışık ve uzun. Hatta bu sene Martin Fowler, Kent Beck ve David Heinemeir Hansson’un güzel bir sohbeti var. Biraz uzun ama mutlaka izleyin, dinleyin derim… Bu adresten ulaşabilirsiniz.

Devam…

  • Sep
  • 26
  • 2014

Agile Sparrow olup, uçmak ister misin?

Tags: , | View: 121 | Comments:

Agile kavramı dünyada oldukça popüler ve oturmuş bir kavram artık. Hatta kendini kanıtlamış bir çok metodoloji ile de IT sektörü için olmazsa olmazlardan oldu. Ülkemizde yeni yeni farkındalığı oluşmakta. Bu bağlamda Scrum Turkey‘in önderliğinde çok güzel bir program başlıyor. Agile’ı daha iyi tanımak ve öğrenmek için başlatılan, üniversite son sınıf öğrencileri ya da yeni mezunlara yönelik bu program ile, konunun uzmanlarından Agile hakkında ne var ne yok hepsini öğrenme fırsatı yakalayabileceksiniz.

Kasım 2014 – Mayıs 2015 belli zaman aralıklarında gerçekleşecek kamp etkinlikleri ve program hakkında tüm ayrıntıları ve başvuru sürecini http://www.agilesparrow.com/ adresinden öğrenebilirsiniz. İlgilenenlerin şiddetle katılmasını tavsiye ederim…Fırsat güzel, kaçmaz…

agilesparrow

  • Sep
  • 23
  • 2014

Prensip sahibi yazılımlar VOL. I

Tags: , | View: 195 | Comments:

Karmaşık problemleri yazılım ile çözerken, teknik olarak ne kadar fazla bilgiye sahip olsak da, çeşitli noktaları atladığımızda daha fazla karmaşıklık yaratan çözümler ile karşı karşıya gelebiliyoruz. Java’nın JDK’sını çok iyi bilmemize  ya da .NET Framework’ün tüm özelliklerini gözü kapalı sayabilmemize ya da javascript ile client’lar da takla atıp, avuda kalkmamıza rağmen, neden hala yazılım sorunları ile uğraşıyoruz? Ya da geliştirme süresince neden sorunlar ile karşılaşıyoruz?

Teknik yetkinlik dışında, temel bazı prensip ya da tecrübeleri anlama konusunda eksik kaldığımızda, bir çok sorun karşımıza “dann” diye çıkacaktır, çıkıyor da hatta… Bu yazıda yazılım geliştirirken, düşünme şeklimize yön verecek, yol gösterecek bir kaç prensipten bahsetmek istiyorum, -ki eminim bir çoğunuz da adı gibi biliyordur, ya da en azından duymuştur. KISS,YAGNI,SOC,TDD,WET….

overengineeringKISS – Keep It Simple, Stupid

KISS, basitlik ve sadeliğin altını çizen, bence, en önemli yazılım geliştirme prensibi. Basitlik, kulağa olumsuz bir durum çağrıştırsa da, karmaşık problemleri çözmek adına çoğu zaman çok kritik olabiliyor. Basit düşünmek, düşünebilmek problemin temel sebebini görebilmek adına oldukça önemli. Kolay bir yol ile çözülebilecek problemleri ya da başka bir ifade ile, bir kaç satır kod ile geliştirilebilecek bir metodu,  gereksiz ifadeler ile karmaşık hale sakın getirmeyin der bu prensip basitçe. Bunu derken, ihtiyacı en basit şekilde düşünerek, gerçekten ihtiyaca yönelik özellikleri öne çıkarmanın da altını çizer.  Bir sistem ne kadar karmaşık olursa, onun sürdürebilirliğini sağlamak o kadar zor olur.  Tabi, bu prensibi ele alırken, kalite özelliklerini mutlaka dikkate almak gerek. Basit olacak diye kalite özelliklerini görmezden gelirseniz sonuçta ortaya çıkan şey “basit” değil “sığ” olur.

YAGNI – You Ain’t Gonna Need It

YAGNI, ihtiyacımız olmayacak şeyleri sisteme dahil etmemeyi söyleyen bir prensip. KISS’e oldukça benziyor belli noktalardan aslında.  Geliştirme aşamasında, bazen öngörülü(?) davranıp ileride lazım olabileceğini düşündüğümüz sınıfları,metodları yazarız. Bu, hem ileride lazım olabilir(?) öngörüsü, hem de yaptığımız geliştirmeyi daha büyük görmek istememizden kaynaklanıyor aslında.  E-mail atabilmemizi sağlayan bir sınıf ihtiyacımız olduğu zaman “Öyle bir sınıf yazdım ki, hem SMS atıyor, hem e-mail, hem de Push Notification gönderiyor” diye havalara girdiğimizde, zamanı geldiğinde gerçekler tokatı yapıştırır. YAGNI, bu tokatın gelmemesini sağlayan en önemli prensip.  Yazılımlara, sanatsal yönümüzü de kullanarak geliştirdiğimiz/eklediğimiz her özellik, temelinde ekstra maliyet olarak karşımıza çıkacaktır. Talep edilmemiş olmasına rağmen, geliştirdiğimiz bu özellikler ek test eforu, dökümantasyon ve sonrasında da bakım kavramlarını da dikkate almamızı gerektirecektir.  Ek özellikler ile alengirli bir yazılım yapalım derken, aslında daha karmaşık ve daha da karmaşıklığa giden bir yazılım geliştirme ihtimalimiz o kadar artar. O yüzden, ihtiyaç olarak belirtilmemiş geliştirmelerden kaçıyoruz…

Çok fazla karambole gitmemesi için bu prensiplerden parça parça bahsediyor olacağım…O yüzden KISS ve YAGNI ile şimdilik bu kadar. Devamı çok yakında…

  • Sep
  • 23
  • 2014

SQLSaturday #359 İstanbul, 6 Aralık’da…

Tags: , | View: 92 | Comments:

Geçen sene de gerçekleşen,  SQLSaturday etkinliğinin İstanbul ayağı bu sene 6 Aralık‘da İstanbul’da gerçekleşecek. Microsoft’un İstanbul ofisinde 1 gün boyunca farklı oturumlar ile SQL’le alakalı bir çok konu anlatılacak. Yerli ve yabancı, SQL konusunda uzman kişilerin oturumları ile yoğun bir gün olacağını şimdiden söyleyebilirim. Tam olarak etkinliğin programı belli değil ancak konular şimdiden belli olmaya başladı. Programın son hali ve katılım için burayı ziyaret edebilirsiniz.

SQL ve SQL Server ile yoğun bir şekilde çalışıyorsanız kaçırmamanızı şimdiden tavsiye ederim.

Title Speaker Level
SQL Server Deep Dive Denis Reznik Intermediate
AlwaysOn Unplugged: Scalability Solutions with SQL Server 2012/2014 Yigit Aktan Advanced
Building abstract layers for data protection and business logic Uwe Ricken Intermediate
Common TSQL Mistakes Kevin Boles Intermediate
Connection – Session – Request Uwe Ricken Advanced
Correcting Database Corruption: Advanced Techniques Yigit Aktan Advanced
Data quality with DQS components in Integration Services Alexander Karl Intermediate
Database Recovery: Backup and Restore Basics Andrey Zavadskiy Beginner
Deadlocks. Everything that developer needs to know Denis Reznik Intermediate
Deep dive to SQL Server configuration for SharePoint Server Gokan Ozcifci Advanced
Developerlar için SSDT kullanımı Çağlar Özenç Beginner
Dive into the Query Optimizer-Undocumented Insight Benjamin Nevarez Advanced
DMV for administration of indexes Uwe Ricken Advanced
DQS step-by-step with Domain Management, Knowledge Discovery and Matching Policies Alexander Karl Intermediate
Effective T-SQL. To be effective or not to be. Denis Reznik Intermediate
Execution Plans Detail From Zero to Hero Ismail ADAR Beginner
Handling data types in SQL Server tomaz kastrun Intermediate
INSERT / UPDATE / DELETE – deep dive Uwe Ricken Advanced
Introducing Microsoft Azure HDInsight Belkis Ozhorasan Intermediate
Introduction to Reporting Services for SharePoint Gokan Ozcifci Beginner
Let’s cook ‘best SQL Server DBA practices’ Satya (SQLMaster) Shyam Jayanty Intermediate
Making customer segmentation using SQL Server SSAS tomaz kastrun Advanced
Optimizing SQL Server 2012 for SharePoint 2013 Gokan Ozcifci Advanced
Query Processing in In-Memory OLTP (Hekaton) Benjamin Nevarez Intermediate
Replay your workload and save the business! Boris Hristov Intermediate
SharePoint – from distrust to acceptance Gokan Ozcifci Intermediate
SQL Injections and Penetration Testing on SQL Server 2014 Ismail Adar Advanced
SQL Server 2014 New Features Kevin Boles Intermediate
SQL Server AlwaysOn and Clustering,Mirroring and Log Shipping Yusuf Kahveci Advanced
SQL Server Data platform upgrade Techniques, best practices & notes from the field Satya (SQLMaster) Shyam Jayanty Intermediate
SQL Server Query Design and Optimization Recommendations For Developers Ismail ADAR Intermediate
SQL Server: Performance Tuning and Troubleshooting Denis Reznik Advanced
The nightmare of locking, blocking and isolation levels! Boris Hristov Intermediate
Transaction Isolation Levels Deep Dive Yigit Aktan Intermediate
Transaction Log Basics Andrey Zavadskiy Intermediate
Understanding Parameter Sniffing Benjamin Nevarez Intermediate
Unit Testing SQL Server Kevin Boles Intermediate
Unit Testing with SQL Server Data Tools Andrey Zavadskiy Intermediate
Usage of R in SQL Server for better data understanding tomaz kastrun Intermediate
Useful Dynamic Management Views and Functions for SQL Server 2014 Ismail Adar Intermediate
Windowing Functions: THE Reason to Upgrade to 2012+ Kevin Boles Advanced
Write Quick, Readable and High Performance Queries Using Window Functions with SQL Server 2014 Ismail Adar Intermediate
You want rules? You want Policy-Based Management! Boris Hristov Intermediate
  • Aug
  • 29
  • 2014

WCF ile ASP.NET Web API nedir, ne değildir…

Tags: , , , , | View: 510 | Comments:

Servis kavramının, teknolojik olarak çeşitlenmesi ve gelişmesi ile yeni kavramların hayatımıza girmesi, ya da daha çok karşımıza çıkıyor olması bazı karmaşıklıklara yol açıyor gibi. Son zamanlarda gördüğüm, duyduğum ve yaşadığım en büyük karmaşıklık WCF(Windows Communication Foundation) ve ASP.NET Web API‘ın karşılaştırılması. WCF’in kullanımına göre, belki bir noktada ASP.NET Web API ile karşılaştırılabilir ama genel çerçevede ikisi de farklı sepette olan elma ve armut…Haa ikisi de meyve, o ayrı :D

En basitinden WCF, servis odaklı uygulamalar geliştirmek için kullanılan bir geliştirme platformu ya da modeli. ASP.NET Web API ise HTTP, üzerinden RESTful servisler geliştirmek için kullanılan bir framework. Buradaki tek ortak nokta ikisinin de belli amaçlar doğrultusunda servis yaratmak için kullanılması.

serviceASP.NET Web API’den önce WCF’de de RESTful servisler geliştirmek mümkündü. ASP.NET Web API, WCF Web API’nin geliştirilmiş ve dönüştürülmüş hali. Bu dönüşümün sebebinin RESTful servislerinin, WCF’in ağır konfigürasyon alt yapısına gerek duymaması ve ASP.NET MVC modelinin, Web API kavramına daha yakın olması olarak söyleyebilirim.

WCF ile geliştirilen servisler, SOAP spesifikasyonu ile HTTP,TCP,MSMQ gibi transfer protokolleri üzerinden sunulmaktadır. ASP.NET Web API ise HTTP transfer protokolü üzerinden servisler sunmak içindir. Bu tip servislere RESTful servisler deniyor.Internet Media Type olarak adlandırılan veri formatları bu servislerin çıktılarıdır. JSON bunların en çok kullanılan ve en çok bilineni. Bunun dışında XML de olabilir tabi ki.

Genelde ikisinin tercih edilme sebebi, servisi kullanacak client’ların SOAP’ı yorumlayabilme ve yorumlama şekli oluyor. SOAP’ın, browser’lar tarafından direkt olarak yorumlanaması, web uygulamalarında RESTful servislerin biraz daha popüler olmasında önemli bir nokta desem çok da yanılmam sanırım. Client olarak nitelendirilebilecek browser’lar, üzerinde çalışan javascript kütüphanelerinin ve framework’lerinin RESTful servisleri kullanım kolaylığı, geliştirme kolaylığ ile de birleşince RESTful servisler doğal olarak daha çok tercih ediliyor.

WCF üzerinden sunulan servisler, WS-* standartlarına uygun olup, ekstra Transaction, Reliable Messaging Model gibi biraz daha yönetilebilir alt yapılara sahip olurlar. ASP.NET Web API ile geliştirilmiş bir RESTful serviste bunlar pek mümkün değildir. Ayrıca RESTful servisler stateless’dır. State’lerin(durumların) hep taşınmasına yönelik bir yaklaşımı vardır. REST’deki ST’de zaten State Transefer buna denk geliyor… :D

WCF servisi mi ya da ASP.NET Web API ile RESTful servisi mi geliştirim kararı, tamamen ihtiyaca göre verilen bir karar olmalı. ASP.NET Web API ya da RESTful servisler, WCF’den daha iyi ya da onun yerini alacak kavramlar değil. WCF ya da ASP.NET Web API tercihi, servisi kullanacak client’a ve servisin sunulacağı yönteme göre verilmelidir. Aman diyim…

Devam…