Decouple that Decoupled Code
Decoupling code is the process of separating concerns. In programming, it refers to separating the code into pieces and ensuring that each piece works on its own. Kind of like a robot might have a robotic arm that can work independently of the rest of the robot.
While not the first, Ruby on Rails has made decoupling popular in Web applications. Everyone decided to get on the bandwagon here, so even Microsoft came out with an MVC Framework, now in it's 3rd edition. Developers seem to love MVC. It's simple, elegant, and most importantly, it's decoupled.
If you ever do Enterprise development, you'll quickly learn that MVC isn't the only way that apps are decoupled. In many applications, particularly on the .NET side of things, you'll find that code is compartmentalized into components that plug into each other. It's because of this that I am starting to perceive decoupling as happening in layers.
Let me try to map this out. In a very very very broad view of things, there is the Database and the application and those things in between. We'll call these the Database Layer, the Application Layer, and the Service Layer, as this is often how I see things in enterprise code.
Within each layer, however, we find ourselves writing code. The database gets broken up into tables and normalized. Each service in the service layer is broken up with a Model, the webservice front end, and the Application logic. In Visual Studio this is really prevalent because of the way projects are in both appearance and compilation. Here's an example of a WCF Service.
Then things start to get real interesting. We see this on the front end as well. The solution looks like the one for the WCF Service, except the front end is an MVC Application. That's correct, our Decoupled Project, is full of decoupled Applications, and when we get to the front end, we decouple the front end further.
Now, I'm not going to post my opinion on this. I'm not even sure if I have one. But, since we're in the process of decoupling our front end. Why not decouple the View in our MVC project? Enter KnockoutJS. This is a spectacular library for JQuery. It's purpose is to decouple your HTML and Javascript, enabling your javascript to host your Model and your View Model, while your HTML is a crisp clean View. Plus, it has some awesome tutorials.
Now we can use MVVM to decouple our View, which is decoupled from our Web Application, which is decoupled from the Application, which is decoupled from the Data. Dare we decouple further?
While not the first, Ruby on Rails has made decoupling popular in Web applications. Everyone decided to get on the bandwagon here, so even Microsoft came out with an MVC Framework, now in it's 3rd edition. Developers seem to love MVC. It's simple, elegant, and most importantly, it's decoupled.
If you ever do Enterprise development, you'll quickly learn that MVC isn't the only way that apps are decoupled. In many applications, particularly on the .NET side of things, you'll find that code is compartmentalized into components that plug into each other. It's because of this that I am starting to perceive decoupling as happening in layers.
Let me try to map this out. In a very very very broad view of things, there is the Database and the application and those things in between. We'll call these the Database Layer, the Application Layer, and the Service Layer, as this is often how I see things in enterprise code.
Within each layer, however, we find ourselves writing code. The database gets broken up into tables and normalized. Each service in the service layer is broken up with a Model, the webservice front end, and the Application logic. In Visual Studio this is really prevalent because of the way projects are in both appearance and compilation. Here's an example of a WCF Service.
Then things start to get real interesting. We see this on the front end as well. The solution looks like the one for the WCF Service, except the front end is an MVC Application. That's correct, our Decoupled Project, is full of decoupled Applications, and when we get to the front end, we decouple the front end further.
Now, I'm not going to post my opinion on this. I'm not even sure if I have one. But, since we're in the process of decoupling our front end. Why not decouple the View in our MVC project? Enter KnockoutJS. This is a spectacular library for JQuery. It's purpose is to decouple your HTML and Javascript, enabling your javascript to host your Model and your View Model, while your HTML is a crisp clean View. Plus, it has some awesome tutorials.
Now we can use MVVM to decouple our View, which is decoupled from our Web Application, which is decoupled from the Application, which is decoupled from the Data. Dare we decouple further?
Comments
Post a Comment