• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Business layer: flexibility vs. simplicity

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
I've already saw several posts, related to dynamic db, meta data etc. Some of developers use flexible business layer approach, which has no hardcoded data schema. Another approach is to have business logic data, with hardcoded structure. I'm not sure about this flexible data schema solution. It is something like building application on top of Oracle database, without having business objects and working with plain String arrays? How many systems are developed without object-relational mapping? How many systems take advantage of easy future enhancements(considering code complexity and missing business logic in business tear)?
As alternative I'm thinking about real 3-tear approach. Database layer has no idea about business data schema, and uses meta data from db file to validate input from business layer. Business layer provides interface, which is based on business objects only, but internal implementation maps business columns into database ones. So we have two meta data schemas: db meta data(from db file) and hardcoded business meta data. Does this solution sounds reasonable? Thanks for any comment.
 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I don't have an answer to your question, but a procedural approach. My project now
supports two unique databases, though the way the schema definition works is the
same; so, for instance, the number of fields per record could differ, and meaning
of a database column could differ, and the number of bytes per field could differ.
To keep things simple, and so that my JUnit tests continue to work correctly, my
"second" database type is very similar to the original type, except that the number
of system bytes is different, and the number of bytes per record is different.
My suggestion, then, is procedural: at some point, for me, I did this later on in my
project, I introduced the second database; you might do the same and see where
things lead. By the time you get everything working, you may decide, or perhaps not,
that it is simpler simply to hard code the business layer so that it knows, implicitly,
that column 7 has a certain meaning.
Since keeping the business layer 'blind" about the meaning of a column is a form
of indirection, I would see know hurry to implement it immediately, as indirection
can be added during refactoring at a later stage if it is deemed necessary.
Thanks,
Javini Javono
 
Once upon a time there were three bears. And they were visted by a golden haired tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic