Bölüm 2 - Mimari

Platformlar arası uygulamalar oluşturmanın önemli bir tenet'i, platformlar arasında kod paylaşımını en üst düzeye çıkarmaya olanak sağlayan bir mimari oluşturmaktır. Aşağıdaki Nesne Odaklı Programlama ilkelerine uymak iyi tasarlanmış bir uygulama oluşturmaya yardımcı olur:

  • Kapsülleme : Sınıfların ve hatta mimari katmanların yalnızca gerekli işlevlerini gerçekleştiren ve uygulama ayrıntılarını gizleyen en düşük API'yi kullanıma sunmasını sağlama. Sınıf düzeyinde bu, nesnelerin 'kara kutular' gibi davrandığı ve kod kullananların görevlerini nasıl yerine getirdiklerini bilmesi gerekmediği anlamına gelir. Mimari düzeyde, daha soyut katmanlarda kod adına daha karmaşık etkileşimleri düzenleyen basitleştirilmiş bir API'yi teşvik eden Cephe gibi desenlerin uygulanması anlamına gelir. Bu, kullanıcı arabirimi kodunun (örneğin) yalnızca ekranları görüntülemek ve kullanıcı girişini kabul etmekle sorumlu olması gerektiği anlamına gelir; ve hiçbir zaman doğrudan veritabanıyla etkileşim kurmaz. Benzer şekilde, veri erişim kodu yalnızca veritabanına okumalı ve yazmalı, ancak hiçbir zaman düğmeler veya etiketlerle doğrudan etkileşim kurmamalıdır.
  • Sorumlulukların Ayrılması – Her bileşenin (hem mimari hem de sınıf düzeyinde) net ve iyi tanımlanmış bir amacı olduğundan emin olun. Her bileşenin yalnızca tanımlı görevlerini gerçekleştirmesi ve bu işlevi kullanması gereken diğer sınıflar tarafından erişilebilen bir API aracılığıyla kullanıma sunması gerekir.
  • Polimorfizm : Birden çok uygulamayı destekleyen bir arabirime (veya soyut sınıfa) programlamak, çekirdek kodun platformlar arasında yazılabilmesi ve paylaşılabilmesi ve platforma özgü özelliklerle etkileşime devam edilebileceği anlamına gelir.

Doğal sonuç, ayrı mantıksal katmanlara sahip gerçek dünyadan veya soyut varlıklardan sonra modellenen bir uygulamadır. Kodu katmanlara ayırmak, uygulamaların anlaşılmasını, test ve bakımını kolaylaştırır. Her katmandaki kodun fiziksel olarak ayrı (dizinlerde, hatta çok büyük uygulamalar için ayrı projelerde) yanı sıra mantıksal olarak ayrı (ad alanları kullanılarak) olması önerilir.

Tipik Uygulama Katmanları

Bu belge ve örnek olay incelemeleri boyunca aşağıdaki altı uygulama katmanına başvuruyoruz:

  • Veri Katmanı – Geçici olmayan veri kalıcılığı, büyük olasılıkla bir SQLite veritabanı olabilir, ancak XML dosyaları veya diğer uygun mekanizmalarla uygulanabilir.
  • Veri Erişim Katmanı – Uygulama ayrıntılarını çağıranın maruz bırakmadan verilere Oluşturma, Okuma, Güncelleştirme, Silme (CRUD) erişimi sağlayan Veri Katmanı çevresinde sarmalayıcı. Örneğin DAL, verileri sorgulamak veya güncelleştirmek için SQL deyimleri içerebilir, ancak başvuran kodun bunu bilmesi gerekmez.
  • İş Katmanı – (bazen İş Mantığı Katmanı veya BLL olarak adlandırılır), iş varlığı tanımlarını (Model) ve iş mantığını içerir. İş Cephesi modeli adayı.
  • Hizmet Erişim Katmanı – Buluttaki hizmetlere erişmek için kullanılır: karmaşık web hizmetlerinden (REST, JSON, WCF) uzak sunuculardan verilerin ve görüntülerin basit bir şekilde alınmasına kadar. Ağ davranışını kapsüller ve Uygulama ve kullanıcı arabirimi katmanları tarafından kullanılacak basit bir API sağlar.
  • Uygulama Katmanı – Genellikle platforma özgü (platformlar arasında genel olarak paylaşılmayan) kod veya uygulamaya özgü kod (genel olarak yeniden kullanılamaz). Sınıfın gerçek bir görüntü denetimine sahip olup olmadığını veya (b) birden çok ekran veya cihaz arasında paylaşılıp paylaşılamayacağını (örneğin, i Telefon ve iPad) belirlemek için Uygulama Katmanı'na kod yerleştirilip yerleştirilmeyeceğinin iyi bir testidir (a).
  • Kullanıcı Arabirimi (UI) Katmanı – Kullanıcıya yönelik katman, bunları yöneten ekranları, pencere öğelerini ve denetleyicileri içerir.

Bir uygulamanın tüm katmanları içermesi şart olmayabilir; örneğin Hizmet Erişim Katmanı, ağ kaynaklarına erişmeyen bir uygulamada mevcut olmaz. İşlemler son derece temel olduğundan çok basit bir uygulama Veri Katmanı ile Veri Erişim Katmanını birleştirir.

Yaygın Mobil Yazılım Desenleri

Desenler, yaygın sorunlara yönelik yinelenen çözümleri yakalamanın yerleşik bir yoludur. Sürdürülebilir/anlaşılır mobil uygulamalar oluştururken anlaşılması yararlı olan birkaç temel desen vardır.

  • Model, Görünüm, GörünümModeli (MVVM) – Model-View-ViewModel deseni, Xamarin.Forms gibi veri bağlamayı destekleyen çerçeveler arasında popülerdir. Windows Presentation Foundation (WPF) ve Silverlight gibi XAML özellikli SDK'lar tarafından popülerleştirildi; burada ViewModel, veri bağlama ve komutlar aracılığıyla veriler (Model) ile kullanıcı arabirimi (Görünüm) arasında bir geçiş işlevi görür.
  • Model, Görünüm, Denetleyici (MVC) – Yaygın ve genellikle yanlış anlaşılan bir desen olan MVC, Kullanıcı Arabirimleri oluşturulurken en sık kullanılır ve kullanıcı arabirimi ekranının gerçek tanımı (Görünüm), etkileşimi işleyen altyapı (Denetleyici) ile onu dolduran veriler (Model) arasında bir ayrım sağlar. Model aslında tamamen isteğe bağlı bir parçadır ve bu nedenle bu düzeni anlamanın temeli Görünüm ve Denetleyici'dedir. MVC, iOS uygulamaları için popüler bir yaklaşımdır.
  • İş Cephesi – AKA Yönetici Deseni, karmaşık işler için basitleştirilmiş bir giriş noktası sağlar. Örneğin, bir Görev İzleme uygulamasında, , GetTask(taskID) , SaveTask (task) vb. yöntemleri GetAllTasks() olan bir TaskManager sınıfınız olabilir. sınıfı, TaskManager görev nesnelerini kaydetme/alma işleminin iç çalışmalarına bir Cephe sağlar.
  • Singleton : Singleton deseni, belirli bir nesnenin yalnızca tek bir örneğinin var olabileceği bir yol sağlar. Örneğin, mobil uygulamalarda SQLite kullanırken veritabanının yalnızca bir örneğini istersiniz. Singleton desenini kullanmak, bunu sağlamanın basit bir yoludur.
  • Sağlayıcı : Silverlight, WPF ve WinForms uygulamalarında kodun yeniden kullanılmasını teşvik etmek için Microsoft tarafından (büyük olasılıkla Strateji veya temel Bağımlılık Ekleme'ye benzer) uyduran bir desen. Paylaşılan kod bir arabirime veya soyut sınıfa yazılabilir ve kod kullanıldığında platforma özgü somut uygulamalar yazılır ve geçirilir.
  • Async – Async anahtar sözcüğüyle karıştırılmaması için, kullanıcı arabirimini veya geçerli işlemeyi tutmadan uzun süre çalışan işlerin yürütülmesi gerektiğinde Zaman Uyumsuz deseni kullanılır. En basit biçimiyle Zaman Uyumsuz deseni, geçerli iş parçacığı arka plan işleminden bir yanıtı işlemeye ve dinlemeye devam ederken uzun süre çalışan görevlerin başka bir iş parçacığında (veya Görev gibi benzer iş parçacığı soyutlamasında) atılması gerektiğini açıklar ve sonra veriler ve durum döndürildiğinde kullanıcı arabirimini güncelleştirir.

Örnek olay incelemelerinde pratik kullanımları gösterildiğinden desenlerin her biri daha ayrıntılı olarak incelenecektir. Wikipedia'da MVVM, MVC, Cephe, Tekil, Strateji ve Sağlayıcı desenlerinin (ve genel olarak Tasarım Desenlerinin) daha ayrıntılı açıklamaları vardır.