I read the following paragraphs about architecture from Microsoft .Net: Architecting Applications for the Enterprise, by Dino Esposito and Andrea Saltarello:
Whenever you take a declarative approach to coding rather than an imperative approach, you are delegating some responsibilities to some other layer of code—a layer that you don't control entirely. So you're ultimately hoping that the intermediate tool will understand you correctly and won't encounter any trouble of its own along the way. In software development, delegating to a third party makes development faster, but you should guarantee that users get exactly what you want them to.
This doesn't mean that you shouldn't trust Visual Studio 2008 or similar wizard-based products. The point is something else entirely. In a large system, likely being developed by several teams, classic declarative programming just doesn't work. You need to have in your presentation a layer of code that decides what to display, where to read settings, and how to apply them. Declarative programming is still a great option, but only if you write the engine and the wizards.
Can someone explain to me in simple words what exactly declarative and imperative programming are?
Declarative - I will describe what I want you to do, you figure it out (SQL, XSLT).
Imperative - I will tell you exactly what to do, one step at a time (C#, Java).
Examples.
Declarative programming:
<asp:DropDownList runat="server" DataSourceID="ObjectDataSource1" />
<asp:ObjectDataSource runat="server" ID="ObjectDataSource1" ItemUpdating="..." />
Imperative programming:
ObjectDataSource source = new ObjectDataSource();
source.ItemUpdating += ...;
DropDownList list = new DropDownList();
list.ID = "";
list.DataSource = source;
list.DataBind();
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With