CAB (Composite Application Blocks) - WTF????
-
I've read comments and articles 'CAB' developers make about how amazing it is that CAB allows you to create de-coupled applications and how 'disconnected' the UI is from the Business Layer, etc. etc...but to date, I've yet to read a single comment or article explaining why any of that is worthwhile? What am I gaining? Ok great...someone sitting in a cube somewhere with little or no knowledge about what this *specific* application does can write the code to encapsulate all 'modules' under one roof! Woopie? What does that gain you and me? I argue it gains us absolutely nothing. No matter how 'de-coupled' CAB developers claim they are, ultimately there's a file somewhere that contains a list of everything that's included...be that in a Project/Solution file for development or ProfileCatalog.xml file for distribution...the fact is CAB takes physical file requirements and moves them from one location to another solving nothing in the meantime and adding a large amount of barbaric source code just to complete even the simplest of tasks. Ok...how about this: CAB allows us to create 'plugins' that can be shared from one application to another!! Finger-Twirl: You can create 'plugins' without CAB - they're called User-Controls and in fact, that's exactly what a 'module' in CAB ultimately is...a user control with a massive amount of overhead tacked on. We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two. Perhaps my opinion is completely wrong based entirely on my overall lack of knowledge and understanding of CAB but in the last several weeks that I've been investigating CAB I still have not found one single, decent answer to my most basic of questions: What does this gain me? GAIN implies that I get 'something' from CAB that I cannot get without it...and just for the record, saying 'decoupled software' as your answer...is NOT an answer. We lose far more than we gain by decoupling so from my chair decoupling is a negative, not a positive. If you're on the CAB team maybe you can post an answer to the above question.
-
I've read comments and articles 'CAB' developers make about how amazing it is that CAB allows you to create de-coupled applications and how 'disconnected' the UI is from the Business Layer, etc. etc...but to date, I've yet to read a single comment or article explaining why any of that is worthwhile? What am I gaining? Ok great...someone sitting in a cube somewhere with little or no knowledge about what this *specific* application does can write the code to encapsulate all 'modules' under one roof! Woopie? What does that gain you and me? I argue it gains us absolutely nothing. No matter how 'de-coupled' CAB developers claim they are, ultimately there's a file somewhere that contains a list of everything that's included...be that in a Project/Solution file for development or ProfileCatalog.xml file for distribution...the fact is CAB takes physical file requirements and moves them from one location to another solving nothing in the meantime and adding a large amount of barbaric source code just to complete even the simplest of tasks. Ok...how about this: CAB allows us to create 'plugins' that can be shared from one application to another!! Finger-Twirl: You can create 'plugins' without CAB - they're called User-Controls and in fact, that's exactly what a 'module' in CAB ultimately is...a user control with a massive amount of overhead tacked on. We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two. Perhaps my opinion is completely wrong based entirely on my overall lack of knowledge and understanding of CAB but in the last several weeks that I've been investigating CAB I still have not found one single, decent answer to my most basic of questions: What does this gain me? GAIN implies that I get 'something' from CAB that I cannot get without it...and just for the record, saying 'decoupled software' as your answer...is NOT an answer. We lose far more than we gain by decoupling so from my chair decoupling is a negative, not a positive. If you're on the CAB team maybe you can post an answer to the above question.
Elkay wrote:
saying 'decoupled software' as your answer...is NOT an answer
I don't really know about this CAB business, but as soon as someone starts saying "man, you have to see this new shit, it's sooo decoupled it's awesome!" I imagine hours and hours writing config files instead of code. It sounds like quackery to me, some BS idea invented by guys wearing turtle-necks and sipping their mocha-ball-sack-flavoured lattes. Sorry, nothing about CAB in particular (I thought you meant the old *.cab files at first...) but I'm glad to hear not everyone is swayed by this "loosely coupled" mumbo-jumbo. Dirty little script-kiddies...
-
I've read comments and articles 'CAB' developers make about how amazing it is that CAB allows you to create de-coupled applications and how 'disconnected' the UI is from the Business Layer, etc. etc...but to date, I've yet to read a single comment or article explaining why any of that is worthwhile? What am I gaining? Ok great...someone sitting in a cube somewhere with little or no knowledge about what this *specific* application does can write the code to encapsulate all 'modules' under one roof! Woopie? What does that gain you and me? I argue it gains us absolutely nothing. No matter how 'de-coupled' CAB developers claim they are, ultimately there's a file somewhere that contains a list of everything that's included...be that in a Project/Solution file for development or ProfileCatalog.xml file for distribution...the fact is CAB takes physical file requirements and moves them from one location to another solving nothing in the meantime and adding a large amount of barbaric source code just to complete even the simplest of tasks. Ok...how about this: CAB allows us to create 'plugins' that can be shared from one application to another!! Finger-Twirl: You can create 'plugins' without CAB - they're called User-Controls and in fact, that's exactly what a 'module' in CAB ultimately is...a user control with a massive amount of overhead tacked on. We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two. Perhaps my opinion is completely wrong based entirely on my overall lack of knowledge and understanding of CAB but in the last several weeks that I've been investigating CAB I still have not found one single, decent answer to my most basic of questions: What does this gain me? GAIN implies that I get 'something' from CAB that I cannot get without it...and just for the record, saying 'decoupled software' as your answer...is NOT an answer. We lose far more than we gain by decoupling so from my chair decoupling is a negative, not a positive. If you're on the CAB team maybe you can post an answer to the above question.
Elkay wrote:
ultimately there's a file somewhere that contains a list of everything that's included.
I think the idea is that, should this list change in the future (cuz you want to include something new, or change something already on it) that should be easy to do as the list is designed from the ground up to be dynamic.
Elkay wrote:
You can create 'plugins' without CAB
You can create a C# application with the .Net runtime and vi - but would you want to? And my understanding of CAB is that the 'overheads' is what makes it more than a user control. I fyou only want a user control just create a user control - if you want the added functionality then use it.
Elkay wrote:
We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two.
Simplicity is not the only thing 'we' need, though. We need standardisation, consistency, testability and maintainability. As with so many patterns there's an initial (steep in many cases) learning curve tinged with the FUD factor. I can't speak for CAB, but there's many a developer arguing about using this or that pattern and practice because they don't understand the benefits and fear the unknown.
Elkay wrote:
Woopie? What does that gain you and me?
Well, it means we don't have to develop that code, which is tested, and that guy in the cubicle is cheap.
Elkay wrote:
GAIN implies that I get 'something' from CAB that I cannot get without it.
Why 'that you cannot get without it?' You can obviously develop software in a myriad different ways, to achieve the same result. The gains are a standardisation of the practice in question.
Elkay wrote:
We lose far more than we gain by decoupling
Well if that's your opinion then obviously anything that aids decoupling isn't for you - but doesn't this come into one of those arguments like the Store Procedures vs Sql in application arguments? If you prefer one over the other and are aware of the pros and cons, then you choose your side and stick with it. I personally like the idea of mostly decoupled software - but decoupled to a point. If I worked for a software house constantly developing app
-
I've read comments and articles 'CAB' developers make about how amazing it is that CAB allows you to create de-coupled applications and how 'disconnected' the UI is from the Business Layer, etc. etc...but to date, I've yet to read a single comment or article explaining why any of that is worthwhile? What am I gaining? Ok great...someone sitting in a cube somewhere with little or no knowledge about what this *specific* application does can write the code to encapsulate all 'modules' under one roof! Woopie? What does that gain you and me? I argue it gains us absolutely nothing. No matter how 'de-coupled' CAB developers claim they are, ultimately there's a file somewhere that contains a list of everything that's included...be that in a Project/Solution file for development or ProfileCatalog.xml file for distribution...the fact is CAB takes physical file requirements and moves them from one location to another solving nothing in the meantime and adding a large amount of barbaric source code just to complete even the simplest of tasks. Ok...how about this: CAB allows us to create 'plugins' that can be shared from one application to another!! Finger-Twirl: You can create 'plugins' without CAB - they're called User-Controls and in fact, that's exactly what a 'module' in CAB ultimately is...a user control with a massive amount of overhead tacked on. We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two. Perhaps my opinion is completely wrong based entirely on my overall lack of knowledge and understanding of CAB but in the last several weeks that I've been investigating CAB I still have not found one single, decent answer to my most basic of questions: What does this gain me? GAIN implies that I get 'something' from CAB that I cannot get without it...and just for the record, saying 'decoupled software' as your answer...is NOT an answer. We lose far more than we gain by decoupling so from my chair decoupling is a negative, not a positive. If you're on the CAB team maybe you can post an answer to the above question.
Elkay wrote:
de-coupled applications and how 'disconnected' the UI is from the Business Layer, etc. etc...but to date, I've yet to read a single comment or article explaining why any of that is worthwhile?
Not done much real UI coding then have you? Most people muddle by with bits of UI stuff in their OM or [more commonly] bits of OM in their UI. Stuff is spread across several places repeated etc. Decoupling is the single best thing you can do: the code becomes terser and clearer, do it any other way and you end up with an unmaintainable tangle of spaghetti on any reasonably sized system.
Elkay wrote:
Ok...how about this: CAB allows us to create 'plugins' that can be shared from one application to another!! Finger-Twirl: You can create 'plugins' without CAB - they're called User-Controls and in fact, that's exactly what a 'module' in CAB ultimately is...a user control with a massive amount of overhead tacked on.
I challenge to to plug in a new control without a rebuild or some hand-rolled complicated CAB-like structure. More than allowing controls to be-reused across applications, it allows you to decide which controls are available to a instance running, without a re-build. Handy where you want a pluggable environment I'd say, and it helps certain deployment scenarios too.*
Elkay wrote:
We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two.
It is designed to make life simpler. I fought against CAB in my last place of work, because I though we were applying it for a percieved need for plugability rather than an actual requirement. Had this been a solid requirement I'd would have been all for it, it would have certainly made many things easier.*
Elkay wrote:
Perhaps my opinion is completely wrong based entirely on my overall lack of knowledge and understanding of CAB but in the last several weeks that I've been investigating CAB I still have not found one single, decent answer to my most basic of questions: What does this gain me?
* The problem is that it isn't intended to benefit you it is intended to benefit developers in particular scenarios. That doesn't mean it is useless, it just means it won't provide any gains for you. Don't use it then.
-
Elkay wrote:
ultimately there's a file somewhere that contains a list of everything that's included.
I think the idea is that, should this list change in the future (cuz you want to include something new, or change something already on it) that should be easy to do as the list is designed from the ground up to be dynamic.
Elkay wrote:
You can create 'plugins' without CAB
You can create a C# application with the .Net runtime and vi - but would you want to? And my understanding of CAB is that the 'overheads' is what makes it more than a user control. I fyou only want a user control just create a user control - if you want the added functionality then use it.
Elkay wrote:
We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two.
Simplicity is not the only thing 'we' need, though. We need standardisation, consistency, testability and maintainability. As with so many patterns there's an initial (steep in many cases) learning curve tinged with the FUD factor. I can't speak for CAB, but there's many a developer arguing about using this or that pattern and practice because they don't understand the benefits and fear the unknown.
Elkay wrote:
Woopie? What does that gain you and me?
Well, it means we don't have to develop that code, which is tested, and that guy in the cubicle is cheap.
Elkay wrote:
GAIN implies that I get 'something' from CAB that I cannot get without it.
Why 'that you cannot get without it?' You can obviously develop software in a myriad different ways, to achieve the same result. The gains are a standardisation of the practice in question.
Elkay wrote:
We lose far more than we gain by decoupling
Well if that's your opinion then obviously anything that aids decoupling isn't for you - but doesn't this come into one of those arguments like the Store Procedures vs Sql in application arguments? If you prefer one over the other and are aware of the pros and cons, then you choose your side and stick with it. I personally like the idea of mostly decoupled software - but decoupled to a point. If I worked for a software house constantly developing app
_Maxxx_ wrote:
think the idea is that, should this list change in the future (cuz you want to include something new, or change something already on it) that should be easy to do as the list is designed from the ground up to be dynamic.
Can you add to your .XML file and suddenly *poof* it shows up in your application? No. You have to 1) Shut down the original EXE. 2) Deliver whatever it is you wrote to that machine. 3) Restart the EXE. If your lil magic square of bland-UI whatever has zero connection to the rest of the application then what have you gained vs writing a user control that looks better, operates better and was faster to build? Again - I say, 'Nothing' and your previous comment to not prove otherwise.
_Maxxx_ wrote:
You can create a C# application with the .Net runtime and vi - but would you want to? And my understanding of CAB is that the 'overheads' is what makes it more than a user control. I fyou only want a user control just create a user control - if you want the added functionality then use it.
Once again, you have put the cart before the horse - i am asking WHY SHOULD I USE IT? WHAT DO I GAIN?? Just saying, "Well if you use it then you'll have it there to use" is hardly a valid reason to substantially increase development time because of the code-bloat associated with CAB.
_Maxxx_ wrote:
...but there's many a developer arguing about using this or that pattern and practice because they don't understand the benefits and fear the unknown
OMG seriously?? Ayende said it best when he said, "The P&P team doesn't work with their tools on real applications. Basically, these tools are created in vacum, not by having to solve real world problems." and also, "When looking at the stuff that the P&P produce, I see things that are extremely complex to their purpose, hard to use and maintain, and don't really add any value to me from where I stand today. I am not speaking blindly here, it took me 40 minutes to repreduce the policy injection block. Even if some of the stuff that they are producing has good stuff in it, it is usually in a form too abstract to be readily used. The CAB is a good example, I like some of the ideas there, but it comes with so much weight around it that it is not worth bothering. I can build on the same ideas in half a day and end up with a far more light wieght approach, easily
-
Elkay wrote:
de-coupled applications and how 'disconnected' the UI is from the Business Layer, etc. etc...but to date, I've yet to read a single comment or article explaining why any of that is worthwhile?
Not done much real UI coding then have you? Most people muddle by with bits of UI stuff in their OM or [more commonly] bits of OM in their UI. Stuff is spread across several places repeated etc. Decoupling is the single best thing you can do: the code becomes terser and clearer, do it any other way and you end up with an unmaintainable tangle of spaghetti on any reasonably sized system.
Elkay wrote:
Ok...how about this: CAB allows us to create 'plugins' that can be shared from one application to another!! Finger-Twirl: You can create 'plugins' without CAB - they're called User-Controls and in fact, that's exactly what a 'module' in CAB ultimately is...a user control with a massive amount of overhead tacked on.
I challenge to to plug in a new control without a rebuild or some hand-rolled complicated CAB-like structure. More than allowing controls to be-reused across applications, it allows you to decide which controls are available to a instance running, without a re-build. Handy where you want a pluggable environment I'd say, and it helps certain deployment scenarios too.*
Elkay wrote:
We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two.
It is designed to make life simpler. I fought against CAB in my last place of work, because I though we were applying it for a percieved need for plugability rather than an actual requirement. Had this been a solid requirement I'd would have been all for it, it would have certainly made many things easier.*
Elkay wrote:
Perhaps my opinion is completely wrong based entirely on my overall lack of knowledge and understanding of CAB but in the last several weeks that I've been investigating CAB I still have not found one single, decent answer to my most basic of questions: What does this gain me?
* The problem is that it isn't intended to benefit you it is intended to benefit developers in particular scenarios. That doesn't mean it is useless, it just means it won't provide any gains for you. Don't use it then.
Keith Barrow wrote:
Not done much real UI coding then have you? Most people muddle by with bits of UI stuff in their OM or [more commonly] bits of OM in their UI. Stuff is spread across several places repeated etc. Decoupling is the single best thing you can do: the code becomes terser and clearer, do it any other way and you end up with an unmaintainable tangle of spaghetti on any reasonably sized system.
It's all I do - design applications look and feel...there is no 'muddling.' I do agree with you 100% about one of your comments: CAB would be PERFECT for massive cube-shops like Insurance companies or Financial institutions.
Keith Barrow wrote:
I challenge to to plug in a new control without a rebuild or some hand-rolled complicated CAB-like structure.
They're called "USER CONTROLS" and there's something like 35,000 right here on CodeProject. Some are actually pretty cool and omg...you can just plug em in and they work!
Keith Barrow wrote:
...More than allowing controls to be-reused across applications, it allows you to decide which controls are available to a instance running, without a re-build
SO WHAT??? Why would that even be useful? I still see no advantage in writing something so generic that it can be used within multiple applications as-is when those instances are uber rare and again...a user control would pretty much cover that.
Keith Barrow wrote:...instance running, without a re-build. Handy where you want a pluggable environment I'd say, and it helps certain deployment scenarios too.
CERTAIN DEPLOYMENT SCENARIOS? CAB Deployment - You have this .EXE (often referred to as the 'Shell') and it runs independent of the module that choke its almost certain MDI interface...there's an XML file that directs the Shell what OTHER .exe's will get loaded and run (either at launch or via some trigger.) Your department has been working hard for the last 18 months on its CAB module (form/user control) that displays a Contact's First, Last and Middle names... And because you wrote it as a CAB module you can distribute JUST YOUR MODULE.EXE, right!??!?? Wrong. You have to tell Shell.EXE to STOP so you can load the new module...then you have to tell Shell.EXE to start back up again. The ONLY thing you 'gain' is that instead of having to re-release a 700-800k exe you only
-
I've read comments and articles 'CAB' developers make about how amazing it is that CAB allows you to create de-coupled applications and how 'disconnected' the UI is from the Business Layer, etc. etc...but to date, I've yet to read a single comment or article explaining why any of that is worthwhile? What am I gaining? Ok great...someone sitting in a cube somewhere with little or no knowledge about what this *specific* application does can write the code to encapsulate all 'modules' under one roof! Woopie? What does that gain you and me? I argue it gains us absolutely nothing. No matter how 'de-coupled' CAB developers claim they are, ultimately there's a file somewhere that contains a list of everything that's included...be that in a Project/Solution file for development or ProfileCatalog.xml file for distribution...the fact is CAB takes physical file requirements and moves them from one location to another solving nothing in the meantime and adding a large amount of barbaric source code just to complete even the simplest of tasks. Ok...how about this: CAB allows us to create 'plugins' that can be shared from one application to another!! Finger-Twirl: You can create 'plugins' without CAB - they're called User-Controls and in fact, that's exactly what a 'module' in CAB ultimately is...a user control with a massive amount of overhead tacked on. We need tools that make our lives simpler not so overly complex that suddenly it takes six engineers where previously it took two. Perhaps my opinion is completely wrong based entirely on my overall lack of knowledge and understanding of CAB but in the last several weeks that I've been investigating CAB I still have not found one single, decent answer to my most basic of questions: What does this gain me? GAIN implies that I get 'something' from CAB that I cannot get without it...and just for the record, saying 'decoupled software' as your answer...is NOT an answer. We lose far more than we gain by decoupling so from my chair decoupling is a negative, not a positive. If you're on the CAB team maybe you can post an answer to the above question.
I have been working with an application build using CAB, since last 2 months and i keep cursing the other company who made it. The poor architecture and bad design make it horrible. The simple tasks such as highlight on up-down key for a row in grid takes 8 seconds. The generate report takes more than half-hour sometimes, which is expected in less than minute in almost all cases. Even for a single update SQL statement, they fire 1000's of deletions and insertions, without stored proc, in compact database. Changing highly decoupled code is very tough, when you are not accompanied by developer team as whole. And No Documentation!