|
|
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
Interesting! 
But did you notice under his profile, he is being shown as a "Member since Thursday, January 2, 2014 (6 months)", but if you look at his reputation graph, it's showing the rep points since 2009. 
Whether I think I can, or think I can't, I am always bloody right!
|
|
|
|
|
No I didn't. Shall I call the police or something?
Regards,
Rob Philpott.
|
|
|
|
|
Just now. After you gave the link. 
Don't mind those people who say you're not HOT. At least you know you're COOL.
I'm not afraid of falling, I'm afraid of the sudden stop at the end of the fall! - Richard Andrew x64
|
|
|
|
|
It's a feature. 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
|
Sandeep Singh Shekhawat wrote: You are always right!!
Please, tell my wife! 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
He is most definitely a Legend Author. Especially with his 0 upon 0 amounts of articles he wrote
Wow! I must say I think I am short 20K author points by the look of it 
Loading signature...
. . . Please Wait . . .
|
|
|
|
|
It seems to me that it is "enterprisey" to write layer of abstract code.
In fact I am often criticized as "not liking layers"
So first I'd like to say what I thing about architecture then ask my question
A crux of contention is:
=======================
I would argue writing layered code is not an end of its own (at least not reasonably).
I would argue an end of its own is (simple maintainable code, i.e.) probably be these few properties:
- modular (people can work on their bit independently)
- dependencies flow down (top level use low level, low level do NOT use top level)
- simplest / unobtrusive as possible shell / architecture to glue stuff together
this *might be* layered / interfaced too but this is not the purpose...
What I often see and I wonder how prevalent and wonder how common it is
=======================================================================
Layered / interfaced as hell code which takes weeks to understand to solve problem as simple as adding 1 + 2.
Is that a common pattern? I suspect it is!  
|
|
|
|
|
Super Lloyd wrote: is not an end of its own
Correct.
Super Lloyd wrote: Is that a common pattern?
Not in my experience. But it depends on the how big a project it is too. I have written only one application with more than a Data Access Layer beneath the application.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I always keep my UI layer and any DB layer separate - it is simpler to just ram code accessing the DB directly from a View, but so totally unmaintainable beyond trivial examples that I just don't do it. I also almost always have a 'service' layer which stitches the two together, rather than calling the Db later from the UI layer.
Other than that, I tend to be fairly flexible on layers depending on the project.
I agree about the over-complexity introduced sometimes - my logic is that a well written and modular project can be expanded into more abstract layers, should that be necessary, quite easily if it is easily maintainable and modular in the first place - and building abstraction on abstraction just because it makes some intrinsic sense to a developer, in my experience, slows development and can increase bugs as new developers don't understand how it hangs together - and nobody ever spends the time to train newbies!
Quote: Super Lloyd wrote: simplest / unobtrusive as possible shell / architecture to glue stuff together
That's the one that gets me most. When someone uses some framework or other (especially if they use something and then modify it, and don't document anything) I have often found that the use of the framework has been chosen without much knowledge - so the developers learn on the job, invent work-arounds, until the whole thing is a bit of a mess, nobody really understands how it is meant to work, and new devs coming into the project don't have a cat in hell's chance of being productive for weeks.
Still, I'm an old fart, so what do I know?
PooperPig - Coming Soon
|
|
|
|
|
I usually keep some sort of scheme like in these two excellent articles 
1. Building a Framework - Part I (DAL)[^]
2. Building a framework - Part II (Utilities)[^]
although that can differ a bit from project to project. My major concerns regarding this, is code separation. It forces me to keep things simple. It also allows me to reuse things, which is handy when you're working on multiple applications.
|
|
|
|
|
What? Something like this?[^]
Regards, Stewart
|
|
|
|
|
Yeah!....
|
|
|
|
|
Layering can be essential to avoid spaghetti and headaches.
Imagine a collection of diagnostic tests written into a prototype, then re-written into a CRM wizard.
Then keep adding new tests, and testing would require rewriting the prototype and the wizard each time.
Or- write each test into a dll, referenced in the prototype and wizard by simple xml.
Adding new tests means just extending or altering the xml and a little wizard interface adjustment.
|
|
|
|
|
Simon O'Riordan from UK wrote: Adding new tests means just extending or altering the xml and a little wizard interface adjustment.
Which is only true if in fact there is a prototype and wizard.
If there is only one or the other then there is no benefit.
Problems arise when developers (plural) or developer (singular) decide that even though there is one instance that in some mythical future there might be more. (And I want to emphasize that they do this without even a glimmer that such a possibility exists.) And thus conclude and require that extra layers be added to support this mythical functionality.
|
|
|
|
|
My principles(I do REAL software in an ENGINEERING company - you've probably heard of that) are rolling out new extension requirements regularly. Now I know you want the five pound argument, but unfortunately you are not paying my bills.
|
|
|
|
|
Simon O'Riordan from UK wrote: My principles(I do REAL software in an ENGINEERING company - you've probably heard of that)
And management of your phone at least at one time was written by me.
And a very good chance that if you used a credit card in the US in the not too distant past then you had a transaction processed by software I wrote.
So now that both of us have proven that we are actual business professionals - my point stands.
If you have extensions being regularly rolled out then you
1. Do in fact have multiple examples already.
2. Probably do in fact have an idea of new instances in the future that will require more flexibility in your design.
Those two factors however are exactly what I said some developers do NOT have. Yet they insist on inserting the same flexibility and of course they will be paid for that time even in cases where it will never be used.
And in point of fact I know of specific example where at least one developer (could have been more) added a complex feature into an API and after several major versions of the software there was NO use of the feature. (This by the way was an API and not a UI toggle that no one bothered pushing.) And when I queried business analysts with years of experience in the industry they could not come up with any idea at all why this feature would ever be used.
Actually for that feature the reason I figured out it wasn't used was because it in fact was coded wrong. It would not have worked if used. Which is why I went looking for the answer for why it existed in the first place.
|
|
|
|
|
Ah, cool. Yes, I was stateside 2008. Kudos, mate. I am looking after operating systems and various other stuff on a tall stack for the Equator robotic gauge. The company was founded by the ex-chief designer of Rolls-Royce Aero Engines specially to do metrology.
Look us up on the web; 'Renishaw'.
The gauge is a beauty; it uses the 'comparator' method to be extremely repeatable rather than absolutely accurate. Ideal for volume production where the product changes frequently.
|
|
|
|
|
Well layered code provides for shearing layers[^] which allow different parts of the application to evolve somewhat independently.
The value of this increases with increasing application/team size so yes it is more "enterprisey".
|
|
|
|
|
I would say that if the app you are working on calls for "simple maintainable code" then yes, what you list is just fine, but typically what I have seen is that apps dictate the architecture - or at least they should!
If an app needs maintainability and features that layering provides then yes, use layers. If it doesn't and needs to be fast as hell, or meet some other requirement that layers does not provide, then don't use layers. I guess my point is that the apps I have seen don't always have the same requirements and therefore need to be architectured differently to meet those requirements. My 0.02
- joe
|
|
|
|
|
Layers are an architecture design pattern that's often applied to help break the design up into manageable pieces or to isolate levels of functionality. Done right, they also define an interface that developers can write to, which makes breaking the work up across multiple developers much easier and makes it easier to replace large sections of functionality.
Developers that came out of large enterprise organizations do seem to be more prone to apply that architecture pattern, in my mind sometimes without much justification. And yes, needed or not, it does gum up the works to some extent. However, I wouldn't consider it bad, merely a design choice.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Any reasonably sized system (i.e. anything that isn't so small you wouldn't be hiring pros to write it for money) can generally benefit from at least the classic 3 tier model (data source or data access; application logic; presentation and user interaction). These layers should, as you say, be genuine layers (one directional dependencies) and that usually requires interfacing if data flow can be two way.
It certainly shouldn't be done 'just because', but layering is a common architectural pattern for good reason, and if I see an architecture without layering in it, I'm going to assume it's just a horrible mess unless someone can give me a good reason why they haven't done at least the classic 3 layers.
|
|
|
|
|
Super Lloyd wrote: I would argue writing layered code is not an end of its own (at least not reasonably).
Seems reasonable.
Super Lloyd wrote: What I often see and I wonder how prevalent and wonder how common it is
At least in my experience people seem to become enamored and/or comfortable with some idiom that requires layers and defend it by quoting what the model does and are incapable of explaining how it applies to the current business need.
Since I get paid either way and, very likely more with the more complex models, and since those very same people, given their inability to even tie the idiom to the business need, I figure trying to make them understand why it is overkill and just let it go.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
