Facades, Repositories, and Model-View-Whatever

This week, in a couple different contexts, I saw the debate emerge as to whether or not an application’s UI can be developed prior to the data end-points it requires being available or finished. While obviously the completed end-to-end application cannot be finished, I see no reason why any UI, following any MV* pattern, cannot be completed independent of it’s data dependencies. By completion I mean rendering, input validation, and error handling related to all CRUD operations; as well as all concomitant unit tests. I also think this can be done even without any initial agreement on the end-points’ contracts, and whether the data is simple or complex. And I think it can be done easily with modern design patterns, and that the majority of people would agree with me and find it obvious. All that is required is an agreed upon specification or acceptance criteria that both the front-end and mid-tier developers adhere to.

Anyone doing UI development following a MV* (model-view-“whatever”) pattern can define a view-model that represents the data the UI tier receives from the mid-tier for rendering, or the data the UI submits to the mid-tier. This view-model can be a facade of any models defined in the mid-tier and need not map exactly to any one mid-tier model. For that matter, so long as the acceptance criteria is well-defined, we need not know how the mid-tier developer is going to define his models. Let’s call our view-model MyViewModel. MyViewModel will contain an identifier property that is also a facade, and let’s say we define it to be of type MyViewModelId. This allows it to be any primitive, composite or custom type.

Following from that, the UI developer can define an interface something like the following:

interface IDataRepository
{
    MyViewModelId Create(MyViewModel data);
    MyViewModel Read(MyViewModelId id);
    void Update(MyViewModel data);
    void Delete(MyViewModelId id);
}

At this point it should be obvious where this is going, but let’s continue for the sake of completeness. The UI developer would then define a class, say MyDevelopmentRepository, that implements the IDataRepository interface. The developer could stub these interface members, or even have them interact with a basic data store (even as simple as the file system). This class can be instantiated in the controllers (or handlers, or whatever) with the appropriate method being called such that he can build the UI as if he is calling the actual end-point(s). He can then define further repository classes that implement the IDataRepository interface, that represent different test and error cases, and he can swap these repository classes in place of the MyDevelopmentRepository in code to develop for different cases and provide his unit tests.

Then, when the end-point(s) are finally finished and we’re ready to do integration, the UI developer defines one final repository class–say MyMidtierRepository–that implements IDataRepository, and additionally has private members that maps the view-model to the end-point models (and vice versa), as well as serializing and deserializing the identifier. The CRUD operators would then internally call their corresponding end-points and map the view-model to the end-point model(s). This new repository is then swapped in, and we’re done (well, we should do integration testing). In addition to allowing the developer build the UI prior to the end-points(s) being completed, and allowing unit test to be built, this approach also insulates the UI code from any changes to how the data is retrieved. If at some point the data comes from a different source, we simply swap in a new repository.

And that’s it. I think it’s that simple. Perhaps I’m missing something, and I put this out there for anyone to point out to me what that may be. Else I really do see no reason why a UI can’t be developed independent of the end-point(s).

Advertisements

Book Review: JavaScript Promises Essentials (PACKT Publishing)

With ECMAScript 6 on the horizon of becoming the JavaScript standard, JavaScript Promises Essentials (PACKT), by Rami Sarieddine, proves to be a timely release.  A relatively quick read, though technical and not always easy, at 90 pages–which includes the preface, appendix and index–this is more of a small booklet and may cause the a consumer to take pause if thinking of buying the hard-copy version at over $20 (the electronic version is going for $9.99).  (For disclosure purposes, PACKT gave me access to a free electronic version of this book in exchange for posting this review on Amazon and front-end-fu.com).  If you can get by the price, though, I found the content of the book to be generally quite good with a couple annoyances I’ll get into shortly.

My personal introduction to the promise pattern came a couple years ago when I started looking into Windows 8 app development with WinJS, which includes an intuitive implementation of promises that conforms to the Promises/A standard.  With my positive introduction to this pattern–which is much more intuitive manner of handling async responses by chaining promise objects and passing your callbacks into the promises then method, rather than nesting your callbacks–I then started looking into Deferreds in jQuery.  In all honesty, though, I find I rarely use them as I find the jQuery implementation to be not at all intuitive.  So it is with this background, I dove into Sarieddine’s work.

There is a lot to like in this book.  He does a good job explaining how the Promises/A+ pattern works, how it differs from the Promises/A standard, where it is in terms of standardization with ECMAScript 6 and current browser support, what some of the libraries are out these that will polyfill support in the interim, and how error handling is done.  Additionally, he steps us a through an implementation of a basic Promises/A+ compliant promises object model.  I often times found myself saying I wish it would explain such-and-such, and within a few pages it would.  One such instance was I wished he would show us how to convert a jQuery Deferred into a promise, and then he did so with the Q and Promise libraries (p. 26).

My quibbles with the content are small-ish.  The first is the limited discussion about jQuery Deferreds, which doesn’t go much beyond saying they don’t follow a standard and quickly demonstrating how to convert them to promises with existing libraries.  Given the prominence of jQuery out in the wild, it deserves a fuller discussion even if not compliant with how standards are panning out.  Speaking of prominence, there is an entire chapter devoted to promises in WinJS, which does seem a bit much given WinJS hasn’t exactly taken the JavaScript world by storm.  But hey, that’s where I first encountered them (though I’ve chosen a lot of losers in my life with my experiments).  And if you happen to use WinJS, well, here you go.

The book also tends not to use practical examples, but rather the examples tend to be functions that return messages of the alert(“Hello there”) variety.  One in-depth practical example, maybe creating a mash-up calling into an API would, perhaps, help drill home how useful promises are, rather than being left simply with theoretical promise.  This likely would make a better chapter than the chapter devoted to WinJS.

And, while I hate to be that proverbial guy, the editing job on the book needs some serious work.  Throughout it appears auto-capitalization is used on function names if they are the first word in a sentence.  With promises, where the methods have name like “then”, this can make for a confusing read as on first read you think it’s the word “Then,” when it’s actually the method “then.”

But having said that, there is a lot of useful content in here, and you will come out of this with a solid understanding of promises and the current state of them.  Worth the read, but debatable if it’s worth the price.

Amazon Rating: 4 out of 5 stars

Book Review: Three.js Essentials (PACKT Publishing)

Three.js Essentials (PACKT Publishing), by Jos Dirksen, proved to be one of the tougher reads I’ve done in a while. When I agreed to review it, I believe PACKT was aware I had no experience nor knowledge of either Three.js or WebGL, or 3-D modelling period. (As a disclaimer, I received a free copy of this book in exchange for this review). I tackled this book from the perspective of someone with years of web development experience, solid knowledge of JavaScript, but having nothing in my background related to WebGL. And that’s what my review will reflect.

In the book’s preface, in a section titled “Who this book is for”, it states:

This book is for developers who already know JavaScript and want to get acquainted [empasis added] with Three.js. … All you need to know is some basic JavaScript and HTML.

“Acquainted” is an interesting choice of words and can be interpreted in a number of ways, I suppose. If what was intended was you’ll come out of reading this book with a basic understanding of what Three.js is about and capable of, then I suppose this book succeeds at that. If it means that a user, such as myself, will come out of this feeling comfortable I could tackle my own projects with it, I’m much less certain that’s the case.

The book is highly dependent on supplementary code samples you can either download from the Packt website or retrieve from GitHub. The book uses this code by highlighting parts of it to explain how to build a number of projects that make up the individual chapters. Where I had issues was the book did not present how to entirely build the projects, making it essential for you to often look between the code examples and what was being described in the book. To learn Three.js from this book I think you’d have to be extremely driven and willing to do a lot of digging beyond what is presented in the book, diving into the code examples (and not necessarily with guidance from the book), and other resources such as the online documentation. At that point, though, you’re not really learning from the book.

The impression I do get from reading the book is if you have some background in Three.js, or similar library, then you may find the book useful and find some of the techniques explained here to provide some “Oh cool! There’s something neat I can do!” moments. But if you are like me, an experienced web developer with no WebGL knowledge, I recommend you look elsewhere.

Amazon Score: 2 out of 5 stars