Недавно открыл для себя Oracle BC4J. По- сути, выходит, что нужен только уровень базы данных с этим фреймворком (Entity object + View object) и представленческий слой + тонкие EJB. Насколько хорошо зарекомендовала себя такая архитектура и применяется- ли где?

Том Кайт, например, вообще пишет так:
never let any developers that write code in java, visual basic, C and the like write any code that has INSERT, UPDATE, DELETE or MERGE in it. Grant them access to a series of stored procedures that return the data they need - or process the transactions necessitated by the system itself.

Вот треды, где он защищает такой подход:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1858995900346985943
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:883929178230
Вот интересный комментарий:
are you building an application that will last forever? Are the technologies and tools you are using today to craft your application going to be used 20 years from now? Will the language you used to code this application still be in vogue in 10 years?

When you ask that question of the data - the answer is easy, yes, this data is relevant and important, we'll be using it a long long time - much longer than the application we build this month (applications come, they go - they go really fast).


Think about this - the year is 1996, web applications are brand new - never existed before. Completely new way to approach things. People wanted web access to their data.

Too bad that the legacy applications were written as CICS transactions on a mainframe, front ended by an ISPF green screen panel.

OBSERVATION: it never fails to amuse me how dead similar CICS transactions are to middle tier applications and how similar the ISPF green screen panel is to a web browser. They are pretty much dead on *the same*

So, when they tried to move to the web, it was really really hard - why? Because the data logic, the data integrity rules, the security, everything - was tied up in the CICS transactions (written mostly in Cobol for example) and building an application that accessed the data directly was FORBIDDEN - for the simple reason that you could not do it safely.

So, many web stores were simply "lipstick on a pig" - they collected data and at the end of the day were batched up to run against the real system. Or, they interacted with the real system by pretending to be a 3278 terminal end user (screen scraping)


And here in the year 2009 - we are inventing 2020's CICS transactions with green screens (j2ee, web browsers).

Кстати, если вы следите за новостями - как раз пару дней назад наделал много шума выход фреймворка Meteor, в котором предлагается размещать SQL прямо в клиентcком javascript'е. По мере того, как браузеры будут развиваться, пойдет мощный откат обратно в 2-звенку.

Кстати, пользователь "ShSerge" как-то писал, что он использует похожий подход. Спросите у него.

Прошлые комменты я написал не в тему, так как подумал, что речь идет о JPublisher.
Оказалось, что речь идет об Oracle Application Framework. Его я использовать не советую.

А почему вы считаете, что BC4J - это смещение нагрузки на СУБД?
BC4J cache is one of the main strengths of BC4J, because it offloads database activity to another location and thus saves the CPU cycles of the database server to fulfill its primary purpose—to manage data. The BC4J layer can cache rows and maintain consistency with the database. This reduces the number of network messages and the amount of database activity required to serve data that has already been served.

Это вообще какой-то Hibernate.