Abstraction vs. Automated Development
While automated development and Abstracted/Loosely coupled software are not mutually exclusive, there are compromises made when using automated development tools.
For example, I love Object/Relational Mapping generation software. Tools like hibernate, nHibernate, Entity Framework, and dozens more, all produce well architected software following extensible patterns. Once you modify the generated code you raise the risk of not being able to make modifications and continue to generate software from those tools.
So, why would you use them? Many times an ORM generation tool may cause you to spend a lot of time defining mapping strategies between your business objects and your database objects. One interesting thing about a well normalized database is that it can map fairly closely to a good business class design as well. This can leave you with three options:
- 1) Us the business objects as your ORM model, deriving your database design from your classes (fode first design)
- 2) Use your database model as the definition of your business objects (database first design)
- 3) Design both intentionally, and map between then for your ORM generator, or roll you own mapping, or roll the whole thing on your own.
What is it you need to accomplish? Getting software out there so your business functions smoothly. Take short cuts and you pay a big price later. Take too long getting there and you go out of business.
This is an old story; nothing new to many of our readers. The question is, does this preclude the use of any 4GL tool? If not, where are they appropriate. If so, how to you meet the demands of your companies vast hunger for software optimization?
Drop me a line through Email to btaylor@sswug.org or leave a comment here.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
Go Beyond Basic Up/Down Monitoring
read more)
Featured Script
dba3_fx_LuhnCheckDigitValid
returns 1 or 0 depending on checkdigit validity… (read more)