Master data
Duke Ganote, September 01, 2009 - 2:04 pm UTC
I always thought (among other uses) that APEX sounded like a easy front-end for maintaining single-table Master Data. I wonder if that's what is intended here?
September 01, 2009 - 5:50 pm UTC
I'm not sure what a "single-table master data" is.
but if you needed CRUD screens for it, yes.
APEX has the SQL in Presentation Layer
Karthick, September 02, 2009 - 2:15 am UTC
I am not using APEX (Cant change that). Our application is developed in .Net
Coming to what you said. I just viewed a demo application available in the apex site. And i could see that the SQL are available in the presentation layer in Apex.
When i go to Region Definition. I can see the SQL in the Region Source.
Does that mean can i scatter my SQL on the front end.
If you use a Non Apex front end then how will you design it. Thats my question. How will you make your SQL Calls. My intension is not in developing a quick application but one that is designed well and maintanable in the future.
September 02, 2009 - 10:32 am UTC
... And i could see that the SQL are available in the presentation layer in
Apex.
...
how so? It is all generated code.
Your application is stored as metadata, you declaratively tell us what to do and at runtime an engine that is apex does it.
... Does that mean can i scatter my SQL on the front end. ...
I don't know what that means?
.. If you use a Non Apex front end then how will you design it. Thats my question. ..
It is a trick question. That would be like asking me "to get from New York to Singapore without a plane, how would you go"
Because I would simply say "I wouldn't go - it would take too long, be too hard, it would be the wrong way to do it given that planes are available"
Separate business logic from presentaion logic
Karteek, September 15, 2009 - 8:25 am UTC
Hi Tom,
I do not have much knowledge on Web development. However I have heard this from many people many a times saying that it is not good to combine business logic (or database related logic) with presentation logic. If it is correct, is Apex doing this way combining sql statements directly with front end code? Please clarify...Thanks
Karteek
September 15, 2009 - 10:07 am UTC
are you programming your UI in APEX or is APEX generating your UI.
(the latter)
I use APEX.
My data logic is 100% contained in stored procedures.
APEX is the UI layer I put on top of that transactional API.
I use constraints for data integrity.
I use procedures for my transactions.
I use APEX for navigation and session state management.
How do you do it?
Business Logic is total nonsense
Associate, September 15, 2009 - 11:34 am UTC
Having come across the term "Business Logic" more times than I would like to recall, I feel obliged to state that there is actually no such sensible meaning, within industry, of the term "business logic".
The term has always been representative of a fad. A term invented by user interface designers to describe the processing of changing the colour of text.
During my four year computer science degree from an established university (where the emphasis is on theory, not practice (we studied one langauge for about 3 months of the four year course), the term "business logic" was mentioned not once. The reason was that it is very difficult, if not impossible, to try to explain a concept that does not actually exist.
Perhaps a few examples might help:
1) a + b. This is not business logic. It is a math function.
2) Fast fourier transform. It is not business logic. It is a math function.
3) Return a subset of rows from a set of database tables. It is not business logic. It is a function to return a subset of rows from a set of database tables.
4) Offering the capability for a user to change the colour of text in an application user-interface. This is not business logic. It is ....
So, please stop using nonsensical phrases, and instead focus on developing correct and efficient solutions, and writing clear and concise documentation. If you focus on these two areas, you will find your productivity will increase significantly!
Calling Business Logic nonsensical *is* nonsensical
djb, September 15, 2009 - 12:24 pm UTC
Business Logic: that logic that processes the data your business needs in an appropriate manner.
1) Customer buys widget X; this allows them to do action X.
2) When Y happens, Z also happens (perhaps starts a new workflow)
I could go on with contrived examples but that's what business logic is. I'm not a fan of buzzwords at all, but "Business Logic" is quite sensible to me.
Apex manages your application - navigation, presenting and submitting data. You *can* put business logic in it, but that really should be on the "C" layer of "MVC". Color for a text field? That belongs in the app, not the business logic.
September 15, 2009 - 1:21 pm UTC
... Business Logic: that logic that processes the data your business needs in an appropriate manner. ...
you just made that up
I define it differently.
they define it differently.
you used circular wording in your definition. According to you - everything is business logic.
... Color for a text field? That belongs in the app, not the business logic. ...
you do understand that most of the world would have called that business logic.
in fact, you did.
When X>50, text field is set to red
Your number 2 is "when Y happens (x>50), Z also happens (text field is red)"
people call everything business logic, then say all business logic MUST be in a separate 'tier' (not in database) and then everything stinks.
This entire "tier" thing bothers the %#@!%#@%$ out of me. People think to do "three tier" you must have three computers and three pieces of software. I do three tier on a single computer with two pieces of software sometimes - it is a logical separation - not a physical one.
browser -> database running APEX
one machine
'two' physical tiers (browser client and database server)
'three' logical tiers (because I code that way)
The definition we use.
Mauricio, September 15, 2009 - 12:59 pm UTC
For the past years we adopt the following nomenclature:
Data logic: everything that transforms and handles your data, managed exclusively by the database via stored procedures and views. For example: generate invoice, add payment, calculate demand, etc. The data logic is also responsible for securing the data and allowing access to the proper users according to roles and options. In our case, Oracle 10g/11g.
Interface logic: everything that presents your data and collects information for any data logic. For example: display invoices in a grid, show a chart displaying historical sales, asking the user for data to be saved or updated, providing a button to trigger a data logic on the database, keyboard navigation, focus management, etc. In our case Adobe Flex or Microsoft Silverlight.
The connection between the two is done via "services". A service in our architecture is something that receives a parameter, asks a data logic to be processed or executed and returns the resulting data to the interface layer in XML via HTTP. Then the interface layer decides how to present this data in whatever form or device that is required to meet the business specifications. In our case the XML is generated by stored procedures on the database via Oracle XML DB (EPG) or Apache (MOD_PLSQL).
We have already built several applications using this architecture and performance is excellent (I would say unbeatable) not to mention the reduced amount of code compared to other architectures. Since we focus on Oracle we use as many built-in features we can like analytical functions, Oracle Text, bulk collect, cube/rollup, partitioning and much more. Oracle is not cheap so use it for your benefit and save development time/effort/maintenance. This is also unbeatable in terms of scalability, we can go to cluster, grid, multiple CPUs, etc, without changing a single line of code. If in some years there is a new trend in interfaces we just change or switch the interface layer/logic but the data logic will be preserved with minimum (if not none) modifications.
Business (il)Logic
Duke Ganote, January 07, 2010 - 1:37 am UTC
Alex Papadimoulis covers it well:
http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx business logic (n.) — any program code (“logic”) that pertains to the purpose (“business”) of a software application. For example "The Customers database table, with its Customer_Number (CHAR-13), Approved_Date (DATETIME), and SalesRep_Name (VARCHAR-35) columns: business logic. If it wasn’t, it’d just be Table032 with Column01, Column02, and Column03."
MVC
A reader, September 20, 2010 - 3:53 pm UTC
Tom:
1) Do you think MVC is good for application development or not?
Does it make maintenance easier?
2) With web toolkit the code for UI and business logic is mixed. Is there a way in oracle to separate that to support an MVC architecture? You still have everything in one box though. Do we have to look at PSP or APEX for that.
September 21, 2010 - 3:30 pm UTC
1) any separate of interface from data logic makes code reuse much better - and leads to (in my opinion) easier to maintain code since the code does one thing (UI or data logic) and you can put a specialist that knows database on data logic and a GUI programmer on UI. And - it lets you rebuild the UI without touching the data logic (which happens very very very often).
2) only if you program it that way. ONLY if you program it that way.
When I wrote asktom, I wrote the data api layer - nothing about UI in there.
Then a guy wrote the UI using APEX on top of it.
In the year 2010 if you are using the web toolkit directly, you are almost certainly doing it wrong. See apex.oracle.com - that is what you should be using.
MVC
A reader, September 27, 2010 - 3:47 pm UTC
Tom:
DO you have a very small example of how you did it?
like what is data API for EDTING an employee info and what is the UI procedure for that.
I am trying to see what you had. Is it pure HTML tags for the UI procedure and SQL and PL/SQL in the data layer. You still have to use pl/sql for you HTP.P functions or to print HTML tags.
You also must have something in your UI to select and fill out the data from DB to display it on screen.
September 27, 2010 - 5:42 pm UTC
there is a transactional api - add_question, add_followup, add_review, delete_followup, etc.
so there is an API that takes the database from one consistent state to the next.
there are apis for searching - they return cursors given a set of inputs.
Very standard (in my world). The way it should be done (in my world). Database code written by someone that knows the database.
Then someone else built the UI on top of it using APEX.
... You also must have something in your UI to select and fill out the data from DB
to display it on screen. ...
all they need to do it build a screen that gets inputs to my API's, a big no brainer from a UI perspective.
There is nothing fancy here - nothing special. Just division of labor. People that know the database - do the database. People that know UI and the UI tools - do that.
And never the two shall interchange themselves.
UI
A reader, September 28, 2010 - 6:33 pm UTC
What about if you do both: the UI and DB logic. I do not really see a full time job for someone doing UI. you have to wear a lot of hats these days.
<<all they need to do it build a screen that gets inputs to my API's, a big no brainer from a UI perspective. >>
Do you mean the inputs/parameters to this UI procedure would be the DB one "get_employee_info" or you would have a DB procedure with OUT parameters that you call in your UI procedure.
September 29, 2010 - 8:24 am UTC
... I do not really see a full time
job for someone doing UI. ...
really - that is what 99.9% of coding seems to be these days - build pretty screens (and be forced to do that 'database stuff' too).
Even if you wear lots of hats though - keeping the division between the bits of code makes sense from a maintenance and reuse perspective. Even for the lone developer. The UI comes and goes and comes and goes - the data, the transactions - theyare needed forever. Asktom has had four major "UI's" in the last 10 years. The transactional layer - not changed very much at all.
So, if you do both, pretend you have multiple personalities and write code as if you were just a UI programmer one moment and a server developer the next.
... Do you mean the inputs/parameters to this UI procedure would be the DB one
"get_employee_info" or you would have a DB procedure with OUT parameters that
you call in your UI procedure. ...
yes - you need both.