It came up in a conversation today. Gmail & OWA are doing much the same thing, using much the same technologies.
Yet it was Gmail who was the Ajax killer application, not OWA.
Why?
It came up in a conversation today. Gmail & OWA are doing much the same thing, using much the same technologies.
Yet it was Gmail who was the Ajax killer application, not OWA.
Why?
I am teaching beginners right now, and we started out from:
using (SqlConnection connection = new SqlConnection(Settings.Default.Database))
{
connection.Open();
using (SqlTransaction tx = connection.BeginTransaction())
{
using (SqlCommand command = connection.CreateCommand())
{
command.CommandText = "SELECT COUNT(*) FROM Books;";
result = (int)command.ExecuteScalar();
}
tx.Commit();
}
}
But they said that they already know this stuff and I am boring, so we moved to this:
return With.Transaction<int>(delegate(SqlCommand command)
{
command.CommandType = System.Data.CommandType.Text;
command.CommandText = "SELECT COUNT(*) FROM Books;";
return (int)command.ExecuteScalar();
});
Where the implementation is:
public static void Transaction(Proc exec)
{
using (SqlConnection connection = new SqlConnection(Settings.Default.Database))
{
connection.Open();
SqlTransaction tx = connection.BeginTransaction();
try
{
using (SqlCommand command = connection.CreateCommand())
{
command.Transaction = tx;
exec(command);
}
tx.Commit();
}
catch
{
tx.Rollback();
throw;
}
finally
{
tx.Dispose();
}
}
}
}
They didn't think it was boring any longer :-)
That made for some interesting diagrams, just to show the flow of the code. The piece of code above covers a lot of topics, next step is to introduce Unit of Work.
They are beginners, so they need to understand the basics well before they can do anything with frameworks, but I just find it so frustrating to work on the naked CLR. It is like a construction worker that can arrive on a building site with an anvil and a hammer, and then need to build all the tools before they can start working.
I am a bit funny when it comes to learning technology, I read about it away from the computer, because otherwise there would be a lot of stuff that I would be doing that would interfer with the process of actually reading a book. Anyway, I am reading Agile Java Development right now, and I got to the point where the author shows how to build a simple page.
The sheer amount of steps required is scaring me. What is more worrying is that the author keeps saying how simple this is compare to other approaches (which I presume Java guys would be familiar with). I keep comparing it to MonoRail + Windsor, and I can't believe that this is so complex.
From an architecture point of view, it is very separated, but from an implementation point of view, it looks messy. Here is the piece of code that caused this post. It is meant to put the current object for the request in the context:
{
if (request.getParameter(TID) != null
&& request.getParameter(TID).trim().length() > 0)
return timesheetManager.getTimesheet(Integer.parseInt(request
.getParameter(TID)), false);
Timesheet timesheet = new Timesheet();
Employee employee = (Employee) applicationSecurityManager
.getEmployee(request);
timesheet.setEmployeeId(employee.getEmployeeId());
timesheet.setStatusCode("P");
timesheet.setPeriodEndingDate(DateUtil.getCurrentPeriodEndingDate());
return timesheet;
}
I am not a Java guy, and I never did anything beyond an applet in Java, so I may be missing something, but is this considered to be a good form of writing your code?
Issuses that I have with the code:
Am I missing something?
(Hm, angering the Java people, angering the P&P people, all I have left now is to anger the Ruby guys and I am set. I shouldn't worry about that, I have a safe place to hide, Cell #6.)
Jeremy has a great quote here:
I think you can almost break coding philosophies into two general camps.
I really like the way he puts it, I'll take door #2 as well. Except that I think that coding does have to be hard, you just have to put yourself in the right level of abstraction.
I am currently thinking about my next project, and I really want to use Active Record, and at the same time, I really want to be able to utilize Repository<T> and decorators chains or not.
A long time ago I made sure that Active Record will be usable without utilizing the "Active Record"-ness of it, so it wasn't that hard to build an IRepository<T> implementation for it, implementing UnitOfWork was a bit more tricky, since I wanted to keep the option to use NHibernate / Active Record at will, as always, another layer of abstraction is always the answer.
I went to such lengths mainly because I didn't want just to get the Active Record RAD capabilities, but to take advantages of the other advantages that it offers (Validation is one, ARDatabind is another, etc). I am not so sure that this is a good idea, though.
I am considerring using Active Record to just generate the mapping (since it has very strong cross-inferencing capabilities), but I am not sure if that is a good idea in the long run...
Any ideas?
No future posts left, oh my!