Ben aslında bir 3. parti API için bir sarıcı olan bir uygulama var. App bir veritabanı kullanmak değildir ve sadece API gerektirir oturum kimliği tek bir çerez saklar.

API kullanıcıların sağlayan bir alışveriş sistemi

-login/register/edit profil / çıkış

-Satın mal

Bağış yapmak-

Bir üye olmak

API benim app bağlanmak için gereken 50 ya da öylesine yöntemleri vardır. Örnek API çağrıları) addItemToBasket (), addDonation (vardır GetUserDetails (vb)

Benim uygulamada sınıflar olmalı ne işe çalışıyorum. İşte ben bugüne kadar ne var:

Classes

1) APIManager() Class Contains the methods that match one-to-one with the methods exposed in the 3rd party API and provides the mechanism to make a connection to the remote API server. So a user would be logged in via

APIManager->loginUser($sessionKey, $uid, $pwd);

ve Uzak API ihtiyaçları olmak istiyorsan, benim app API çağırarak herhangi bir oturum anahtarının statüsünde giriş kontrol edebilirsiniz oturum olarak kullanıcı ayarlamak olacaktır:

 APIManager->isLoggedIn($sessionKey);

2) User() Class This holds methods that contain business logic required before processing API calls such as Register or Login. An example method is:

function login($_POST) {
    //perform sanity checks, apply business rules etc.
    //if certain conditions are met, we may pass in a promo code, $pc

    APIManager->loginUser($sessionkey, $_POST['uid'], $_POST['pwd'], $pc);
}

Ben muhtemelen sadece yerine başına bir kullanıcı sınıfı olan daha giriş sayfasından APIManager için bir çağrı yapabiliriz fark, ama bazı iş mantığı biz aslında API loginUser () yöntemini çağırmadan önce çalıştırmak gerekiyor, çünkü hissettim hissettim Doğru bir kullanıcı sınıfı içinde ele sahip olmak. Ben insanların bu konuda ne düşündüğünü bilmek için istekli olurdu.

3) Basket() Class

Sepet 3. Parti API yönetilen, yani benim app rolü uygun API veri alınır kadar Benim app sepet hakkında hiçbir şey bilmiyor vb sepet görmek, öğeleri kaldırmak, sepete yeni öğeler eklemek için görüşme yapmak olduğunu API, ne de API aracılığıyla gitmeden sepetin herhangi bir değişiklik yapabilirsiniz. Yine, bir Basket sınıfa grup bu ilgili mantığı uygun hissettim. Ön uç web sayfası gibi bir şey diyebilirsiniz:

Basket->addItem(23);

ve bu addItem () Basket sınıfta yöntem şey gibi görünüyor olacaktır:

addItem($itemID) {
   //perform checks, apply business rules e.g. if user is eligible for discount
        APIManager->addToCart($itemID, $discount);
}

addToCart () biz öğeyi işlemek için çağrı üçüncü parti API yöntemi olduğu.

4) Donation() Class

Bu, kullanıcıların bir bağış yapmanızı sağlar. Bağış sepet görünür ve sepet çıkarılabilir. Ben sadece Basket sınıfa ve tüm Bağış nesneye sahip dert bir addDonate () yöntemi ekleyerek düşündüm, ama ... (aşağıya bakınız)

5) Membership() Class

... Üyelikleri aslında bağış türüdür! API 1 yıllık üyelik olarak belli bir hesaba girmeden bağış tedavi değil, düz bir bağış olacaktır. Biz 3. parti API mantık / davranış değiştiremezsiniz.

Ben '1 hesaba 50 $ bağış Yani, 'o zaman sadece normal bir bağış, ama '8 hesap 100 $ bağış ise' sonra tüm üye yararları (düşük fiyatlar, hiçbir pul ücreti vb) ile üye olmak.

Ben bu tasarlamak için en iyi yolu emin değilim burada.

Ben Bağış sınıf oluşturmak ve Bağış yöntemleri tüm Üyeliği gerekli olacağından, sonra Üyeliği ile bu uzanmalıdır. Ancak üyelik, yenilemek () veya getExpiry (), vb gibi ek yöntemlere ihtiyaç olacak

Ayrıca, üye olmak için User uzanan bakmak gerekir? Yine, bir üye Kullanıcı olan çekirdek yöntemlerin hepsi var, ama aynı zamanda sadece üyelerinin olacağı gibi getSpecialOffers () veya getDiscountCode () gibi ek olanları vardır.

En iyi tasarım yaklaşımı nasıl Herhangi bir rehberlik çok duyacağız.

Teşekkürler, James