Wie organisiert man API?

Question

Ich entwerfe eine API und möchte, dass sie einfach zu verwenden ist. Also, wenn ich Kunden, Kontoauszüge und Zahlungen habe. Sind Objekte wie Kunde, CustomerHandler, Statement, StatementHandler, Payment, PaymentHandler sinnvoll? Auf diese Weise kann der Entwickler, wenn er etwas mit Kunden machen möchte, einen CustomerHandler erstellen und dann alle möglichen Funktionen, die man mit einem Kunden ausführen möchte, im Handler befinden.

Methoden wie: CustomerHandler: AddCustomer (Kunde), GetCustomer (customerID), GetCustomerCount() ... StatementHandler: AddStatement (customerID), getStatement Gibt (statementId), GetStatementCount (customerID) ... PaymentHandler: GetPaymentsByCustomer (customerID), GetPayment (paymentID), GetPaymentCountByCustomer (customerID) ...

Auf diese Weise kann der Entwickler, wenn er Zahlungen empfangen möchte, zum PaymentHandler gehen. Mein Kollege dachte, dass Funktionen wie GetPayments (customerID) in eine Klasse gehören, die den Kunden verwaltet. Also, es wäre wie Customer.GetPayments() AS Payments. Aber wenn ich eine andere Entität wie Worker hätte, gäbe es Worker.GetPayments() AS Payments. Also sehe ich die Logik bei beiden Ansätzen. Der erste gruppiert die Dinge zusammen, so dass, egal, von wem die Zahlung kommt, Sie alles aus einer Klasse bekommen, indem Sie Funktionen wie GetPaymentsByCustomer (CustomerID) und GetPaymentsByWorker (WorkerID) haben. Auf diese Weise muss man nicht durch verschiedene Handler- oder Manager-Objekte stolpern, um Zahlungen zu erhalten. Beide Ansätze ergeben für mich einen Sinn, wie steht es mit dir? Oder sind wir beide weg und es gibt einen besseren Weg, dies zu tun? Vielen Dank im Voraus!

Answer 1

In der Debatte "Wo geht das hin?" Entscheide ich normalerweise, wo etwas gehört, basierend auf dem, was es zurückgibt. Wenn Sie eine GetPayment() -Methode haben, die eine Liste von Zahlungsobjekten zurückgibt, sollte sie auf dem PaymentHandler stehen.

Es ist wirklich eine ziemlich subjektive Sache, aber es durch Rückgabetyp zu tun sorgt dafür, dass alles, was im CustomerHandler im PaymentHandler, Kunden Objekte werden Zahlungs Objekte erstellt, usw.

Diese Dinge etwas vereinfachen können, wenn Sie Sie müssen später Änderungen vornehmen, und wie bereits erwähnt, können Benutzer Ihrer API sehr einfach herausfinden, welchen Handler sie aufrufen müssen. Wenn sie einen Kunden benötigen, arbeiten sie mit dem CustomerHandler zusammen.

Es beseitigt auch Verwirrung, wenn Sie eine hypothetische Methode wie GetPayments (customerId, workerId) haben, die Zahlungen für einen Kunden und einen Arbeiter erhalten würde. Wenn Sie den Vorschlag Ihres Kollegen verwenden, ist nicht klar, wohin diese Methode gehen soll, da sie Zahlungen, Kunden und Arbeiter umfasst. Die Kategorisierung nach Rückgabetyp ist fast immer klar, da eine Funktion nur eine Sache zurückgibt.

Answer 2

Wenn Sie eine API entwerfen, könnten Sie vielleicht versuchen, ein paar Mock-ups aus der Sicht Ihrer Benutzer zu schreiben. Implementieren Sie ein paar Anwendungsfälle, auch wenn es nur auf einer Tafel steht, und sehen Sie, welcher Ansatz wertvoller ist.

In Ihrem Zahlungsbeispiel könnten sowohl der Mitarbeiter als auch der Kunde eine zahlbare Schnittstelle implementieren. Wenn Sie dann später ein Objekt hinzufügen mussten, das "bezahlt" werden konnte, würden Sie einfach die gleiche Schnittstelle implementieren. Wenn Sie einen Zahlungs-Handler hätten und eine neue Art von Sache hinzufügen müssten, die bezahlt werden könnte, müssten Sie den Handler ändern, indem Sie eine neue Methode hinzufügen. Mit der Zeit könnte das beschwerlich werden, nehme ich an. Sie könnten natürlich eine Kombination der beiden verwenden und ein Handler-Dienstprogramm haben, das als Front für Ihr Bezahlsystem fungiert.

Answer 3

Sie sind so ziemlich beschreibt zwei Möglichkeiten (Muster) für den Datenzugriff:

• aktiv Rekord - http://martinfowler.com/eaaCatalog/activeRecord.html
• Data Mapper - http://martinfowler.com/eaaCatalog/dataMapper.html

Bitte, erhalten Martin Fowler Buch Patterns of Enterprise Application Architecture und lesen durch alle Vor- und Nachteile. Insbesondere wenn Sie versuchen, Ihre Objekte und APIs als Webdienste verfügbar zu machen, sollten Sie mit dem Data-Mapper-Ansatz fortfahren (wie Sie vorschlagen).

Aktive Aufzeichnung ist sehr beliebt, weil es einfacher ist. Entscheiden Sie selbst, welche Suiten Ihre Bedürfnisse am besten erfüllen.