Coding standards for xsjs by following javascript design patterns. Is that a way to write efficient code ?

[Former Member]

I have been using Hana's server side javascript XSJS for a while. Me primarily coming from a javascript background, i try to write quite efficient, modularized code in javascript. For that the solid & proven way is to follow some of the javascript design patterns. (Learning JavaScript Design Patterns)

Ex-

• Constructor Pattern
• Module Pattern
• Revealing Module Pattern
• Singleton Pattern
• Mediator Pattern
• Prototype Pattern

But with xsjs, surprisingly i haven't found anyone implementing those in their project's code or in the code samples. With xsjslib there comes an option for reusability, but i still find many of the approaches there is to simply create everything as functions.

As i'm trying to follow these pattern on my xsjs/xsjslib code, i would like to get few tips from the experts out here to know whether this is the best way to write a efficient,maintainable,reusable code or is this kind off overhead with xsjs. I sometimes wonder is this just because of developers in SAP ecosystem usually aren't from javascript background and don't really make the best use of javascript !

-Sakthivel

[thomas_jung]

Remember that XSJS should be a lightweight pass-through layer. May times you just are creating a service endpoint where the bulk of the logic is in turn implemented within the database itself. This should be the primary design pattern overall. Following this pattern should leave you with relatively little JavaScript code itself which often falls nicely into simply small functions.

We did teach a Code Review session last year at TechEd on some more advanced JavaScript techniques. We use some of those patterns in our own larger XSJS libraries.  However really I would encourage customers/partners to first look at putting most of their logic in the database itself and then trying leverage that logic via libraries like XSDS.

[Former Member]

That sounds fine - all business logic in the database. This may be good for having one place where all logic is defined and for performance reasons.

What can you say about the arguments that have been raised frequently against having all business logic in stored procedures?

Some of the following good practices/ patterns cannot be easily implemented in stored procedures.

• Interfaces to allow re-usability swapping of implementations and testing dependencies.
• Dependency injection management and avoiding an untraceable tangled web of stored procedure dependecies
• Documentation similar to javadocs that can be automatically created as part of the build process.
• Static analysis to enforce programming standards and conventions
• Inheritance, polymorphism to reduce duplication and complexity and allow extension.