Fork me on GitHub
The journal that this archive was targeting has been deleted. Please update your configuration.

The Juicy Pattern

Juicy Presentation Pattern, yet another presentation pattern, not. JUIPP works on top of ASP.NET WebForms, so I like to think of it as a catalyst, a set of libraries and tools that promote a clean and juicy pattern. Views synchronize themselves to a View Model (VM) and the Views (V) are not supervised by a Controller (V) even though binding is initiated by the Controller. Optionally, Views can catch Behavior and Transition Events, and conditionality synchronize themselves with values of the View Model. Users interact with the Views, and the Views would translate the user inputs to a pair of a Behavior Reference and ViewModel and sends it to the Controller in the form of a Behavior Event object wrapping a behavior reference and a ViewModel. The Container in JUIPP is most times in charge of behavior binding and the Controller sends Behavior Events to the appropriate Behavior (B) in behalf of the Views for data persistence and mapping and the Controller would also accordingly transition one view to the other if the behavior being executed is bound to another view (which makes it a transition behavior).

The concept of Model is behind the scene in JUIPP, as typically only Behaviors are dealing with the actual data (Model). The Model can be a data contract from a web service, or an Entity Model from an ORM (Object Relational Mapping) context. Nevertheless the Model is isolated from the Controller and the Views, by means of the Data Behaviors that can interact with the Model and also translate and map data to ViewModels that the rest of the application can understand and consume as Data Transfer Objects (DTO).

Juicy Presentation Pattern - Class Diagram


Why for SharePoint?

For SharePoint Developers, it’s really an easy answer: SharePoint extends ASP.NET WebForms, so anything that facilitates the development of a SharePoint Farm Application would be useful. In fact, SharePoint 13 still uses ASP.NET WebForms, the same way SharePoint continues to use COM objects (yes, there are still alive).

Learning a new programming language or a new framework is not the challenging part of being a SharePoint Developer, the most difficult part, at least for me, is dealing with poorly written applications with no software standards or conventions and trying to work with other developers as a whole team and at the same time maintaining a clean application. So, the goal of Juicy Presentation Pattern is to introduce an MVC like pattern to have Separation of Concerns (SoC), introduce Convention-over-Configuration (CoC) for consistent and maintainable application and emphasize modularization for easier Test-Driven Development  (TDD) for ASP.NET WebForms.


Why another framework?

Why the need to extending ASP.NET Web Forms? 

Why not just use ASP.NET MVC or ASP.NET Web Pages? 

As an ASP.NET Developer, if you don’t value much having the total control over the HTML markup you render and you rather have ASP.NET Controls taking care of the rendering in a higher level of abstractions, if you appreciate and value event-driven programming, ASP.NET Page life cycle, and the preservation of state over HTTP, then you gravitate towards using ASP.NET WebForms. But with ASP.NET WebForms comes a challenge: you and your team have to constantly remind yourself to have Separation of Concerns (SoC) in your application and maintain a well-structured application by yourself, and that my friend it either requires a serious application design upfront or it requires discipline. ASP.NET MVC challenges ASP.NET WebForms in three counts: ASP.NET MVC has a well structured model where you have SoC by following the Model-View-Controller Pattern, you can easily practice TDD due to it’s modularity, and ASP.NET MVC is intunned with the basics of the HTTP and Web, whereas ASP.NET WebForms abstracts away HTML and HTTP, in the forms of Web Controls, ViewState, postbacks and Page life cycles. An attempt to close the gap, JUIPP adds another layer of abstraction by introducing a presentation pattern that fits the event-driven model of ASP.NET WebForms. It avoids the upfront serious application design, and minimizes the effort of maintaining a well-structured application.