Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Business layer: flexibility vs. simplicity

 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • 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.
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • 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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic