Entity Framework Introduction

I'm starting my new project today and I was informed by our technical architect that we will use the Microsoft Entity Framework. I was so happy when I learned that since I was so depressed, frustrated, and stressed working with Datasets on my previous project. I had almost a month-long of hell dealing with Datasets. I just needed to update fields in several tables but I had to do a lot of stuff to make it happen. Not only that, I encountered a number of ambiguous errors which I can't figure out the causes. I ended up not doing the update on the other tables and creating a new stored procedure. I'm sorry that I keep on ranting about this, I guess I'm not really over with that experience yet.

Anyway, I'm going to discuss a bit about the Entity Framework. The entity framework is Object-Relational Mapping (ORM) tool created by Microsoft to compete with third parties such as NHibernate which have been popular  for the past few years. What is a Object-Relational Mapping? As a software developer, I view it as a method of linking the object classes I created to their corresponding database tables. Usually, I do this through code. Like I execute a SQL Select statement then loop through the result and map them to its approriate property in the object class. As a result, I get a list of objects populated with database data. With the use of an ORM tool, my life is a lot simpler since I don't need to create code to retrieve and manipulate data from the database. I just need to call the appropriate method for the database operation I need to implement, the tool abstracts how this happens. It's really powerful and it can increase one's productivity significantly. However, I believe it has its own share of imperfections which is common in every technology available right now. I'm excited to start developing using this. Hopefully, in a couple of days, I will post an update on how to use the Entity framework and a few insights on its pros and cons.

Visualforce Page Redirection

I needed a button in a standard page of a custom object to do some logic when pressed. Initially, I found out that this could be done through a Global Apex Class. So, I started developing using this approach but I had a hard time passing some parameters to the class from the page. I managed to find some workarounds to address the issue, however, it seemed that I was doing a lot just to make it work. With this, I decided to find another alternative to do the functionality. I realized that I could redirect to a Visualforce page using the button and add method in the controller to do the logic. This time, my problem is that the page redirection does not work after the method is executed in the constructor. After some researching on the cause of this, it turned out that the constructor does not know what to do with the pagereference object it got from the method. As a result, no page redirection happens. To address this issue, you need to call the method in the action parameter of the visualforce page instead of the constructor.

Here's an example:

<apex:page controller="SampleController" action="{!sampleLogicMethodWithRedirection}">

First Stored Procedure

Today, I created my first stored procedure. I'm have mixed emotions about it. I was never a fan of stored procedures throughout my career, I didn't like the idea that business logic will be housed in the database layer. Here are some of my reasons for that:

a). It is hard to debug SP code. I was working with a requirement wherein I need to add an new field to be updated in a table. This task required me to make some modifications to a backend call which calls an SP to update data in the database. Initially, I thought I would just need to add a new field in the SP and update its mapping in the backend. Alas, it didn't work! I encountered a casting error with the SP's parameter against the dataset. I investigated the cause of the error using a variety of methods but I just get the same error message which does not help at all. This was so frustrating since I just wanted to update a single field and how hard could that be?!?! I really, really wanted to create a new implementation on updating the field but I couldn't justify why I need to do so. After two days of investigation, the team decided to create new method to update the field but sad to say it still uses an SP.

b). Hard to maintain in different environments (PT, QA and Prod). It is a pain that you need to update all instances of the SP in different environments every time you have changes. Unlike if you do the business logic in code, you just need to update it in a single place and deploy to different environments. With this, it is less likely you will break something in the other environments compared  to doing an update in all affected environments.

c). Makes the application slower. This is because of the additional layer it needs to go through before the result is obtained by the application. Usually, this is evident when the result from the database layer processing needs to be processed in the application's backend.

However, in spite of these, I guess I'm glad that I created a new SP since it signified that the sprint I was working on for almost a month is almost over! I can't wait to work on something different.