Jonathan Crossland
Posts: 630
Nickname: jonathanc
Registered: Feb, 2004
|
Jonathan Crossland is a software architect for Lucid Ocean Ltd
|
|
|
|
The Every Project Framework - Part 2
|
Posted: May 8, 2009 5:40 AM
|
|
In The Every Project Framework - Part 1, I spoke of partitioning, and abstracting structure and infrastructure. Now Let's talk about how we do that.
Over the last decade, the most prolific and available Architectural Pattern introduced and adopted by business developers is the Layers pattern. Call it by another name, but the concept is around everywhere. Most enterprise systems have open or closed Layers. They have many names, but Data Access Layer, Business Layer and so on, are often used. This a good thing towards raising the level of abstraction, increasing the infrastructure and providing more structure. However, having layers, does not automatically mean your application is on a good footing.
Raising the bar
If you are very skeptical, read the 'Why' section below first.
What do you think of your objects? How do you think of them? Are they transportation, containers, db table wrappers or other? Majority of business applications I see, have objects as a 1 to 1 mapping to a database table and it effectively is a container for a row of data. Some then wrap it into a collection of these rows and you have a table. Is that really what you need? is that efficient and good practice? Does it raise the bar high enough?
The first thing to say is that wrapping your table into an object is not entirely bad, as it is a level of abstraction away from the table.
However, if its at the highest level of abstraction you go to, then you will still have miles of code that you need to place elsewhere. Code such as Context, Security, Permissions, work flow and so on. If you manage all of your Types as a 1 to 1 mapping to the database tables, are you not merely writing code against the database?
If its UI (form) accessing and using -> the DataType Person, then your level of abstraction to the data is almost zero. You have abstracted the concept of a database table and replaced it with a more crude version, which you are populating.
Then the relationships and structure between all these singular Types will slowly come together within your UI, behind your button, in some method of some obscure class. Instead, the singular classes should be a little more structured and the bar should be raised higher, providing your UI with more closer, ready and easier to use objects.
To repeat in more a programmatic way, consider a table named Person.
If you have your UI --> Types --> Table
effectively you have abstracted a Row and Column concept away from the UI and replaced it with a PersonType and a PersonTypeCollection.
That means the UI, must understand how to deal with these Types.
To raise the bar, you would have more abstractions between UI and database
perhaps more like so
UI --> PersonCompositeType --> transaction(PersonDataType1/PersonDataType2) --> Table1/Table2
So PersonCompositeType is at much high level.
Please note:I am not saying that your architecture must look exactly like this, what I am suggesting is that more levels of abstraction can be achieved between the UI and your 1 to 1 mapped Type, that is so commonly found.
Why?
Have you ever had the following in your last or current project?
The UI is a lot more work than writing the "engine" or "business layers"!
Well of course it is, because the level of abstraction for the business layer is so low.
Your project starts quickly, progress seems to be made at speed, and then it slows right, right down....
It would, because, laying out database tables, getting your SQL and business objects in a 1 to 1 mapping is easy. Tying these low level abstraction together into a working application is harder.
Are you using a workflow engine? Are you using a business rules engine? Do you have isolated, stateless services? Do you have wrappers, commands, actions?
If not, then all the workflow, business rules, services are tucked away, most likely in your user interface. If you don't think you need these things, your large projects are most likely failing, running late and/or getting harder and harder to maintain.
Closing thoughts
If you think in "the ways of frameworks". Not as a framework that will be released to the world. Not as a time consuming lets focus on the framework, but rather build it, partition it and expand it within the project, your application will benefit from having more structure and more infrastructure.
Even having one of those is vastly beneficial. That is why a company with their own libraries (infrastructure), can get an application up quicker, even if its not a framework. One or both infrastructure and structure is vital for reuse and time to market. Yet, there is very little training going on at university, or courses in this area.
We should be training developers from their earliest years in software to think about reuse, to understand patterns, and putting rudimentary frameworks together.
Don't let the fact, that there are no perfect frameworks out there, lure you into thinking frameworks are bad. They are just diamonds in the rough. Most importantly, the "good" aspects of frameworks can be used within your application to high rewards. But how do you do it? -- stay tuned...
Read: The Every Project Framework - Part 2
|
|
Previous Topic
