OMG: Object Orientation and Stored Procedures

OMG! how many times have I read the argument "using stored procedures is object oriented programming" just think of the database as an object, and think that each stored procedure is an method of the database....
Now... I am not going to say that using stored procedures is wrong... and I am not going to say that the only correct way of solving software problems is using object orientation... ( I do prefer to use object orientation, I a do prefer to use an object relational mapper instead of a stored procedures, specially for OLTP applications, I think application built that way are more maintainable, more portable between database, can be built faster, scale better, etc,etc)

But for batch processing, stored procedures have a clear advantage, and in my experience many business problems are solved by using an OLTP application, and a short but very important list of batch process... (of course the problem here is that if you built you application using an ORM, probably you have a lot of you business logic already implemented in a presentation-independent form, and, depending on the size of you database, you could program you batch process using your business objects... that has its disadvantages (slower performance that stored procedures) and its advantages (reutilization)... I believe reutilization and maintenance are more important that performance... specially because it is possible to worry about performance in the wrong way: for example Premature Optimization )

But the main point of this post, is that, first, I didn't think that using stored procedures was object oriented programming... it was "procedural programming"... or perhaps even "relational programming" but certainly not object oriented programming (where is the inheritance? where is the polymorphism?) but... after giving it some more thought... I realized that while it could not be "object oriented" it could be "object based"... stored procedures can encapsulate your tables (one of the major advantages of stored procedures) and you can see them as methods to a your "database" object...

So... now... your (OLTP?) system is a thin presentation layer on top of the "database object"... now... is there something in favor... or against that in object oriented design theory?.... mmm.... it achieves Presentation/Business Logic separation... and that is good... but I still feel there is something that doesn't feel right...

OMG! Well, it turns out there is! : Now the database is a God Object.
From Wikipedia: A God object is an object that knows too much or does too much. The God object is an example of an anti-pattern, it goes against divide & conquer ... using a God object is analogue of failing to use subroutines in procedural programming languages, because so much code references it, it makes maintenance difficult...

So... the next time someone tells you that using stored procedures is good object oriented programming... you could answer him or her: Oh My God (Object)! (You could think of it as object based, but, form an object oriented point if view.. it is a recommended solution? couldn't it be seen as an anti-pattern? I am not saying it is wrong, I am just saying that from an object oriented point of view, it might not be the best way to solve the problem... of course, using object orientation might not be the right way to solve this particular problem, after all, object orientation is not a Silver Bullet)

Installing Crystal Reports for VS.NET 2005

After wasting several hours, it turns out that, before installing a WindowsForms for .NET 2.0 application that requires CrystalReports, one needs to install CRRedist2005_x86.msi from C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\CrystalReports it should be easier to find...

In that folder there is also a product.xml that could be for bootstrapping the CRRedist2005_x86.msi with you own .msi so that you can install everything in one step (well, I think it is for that) I have to do more research...

Frederik Gheysels' weblog

Frederik Gheysels' weblog

It was almost as if I heard myself complaining about the bad design most RAD tools promote... what I wonder is.. why couldn't RAD tools promote doing it in "the right way" with proper MVC separation and everything....

It is like the new Java Studio Creator for Sun, the first version copied the DataSet idea from VS.NET and copied it IMHO in the worst possible may (by assuming incorrectly that .NET databinding only worked for the DataSet and not for any .NET object... it is true that it seems like that on the first look, but if you analyze the API closer, you can see it is biased to make it easier for the DataSet, but it does allows for pure object databinding... and what do the Sun guys do? they make it only work for tables! without object support! (they tried to fix it for Java Studio Creator 2, but the object-view has a bug that makes it unusable... I just cant believe it, how could they make such a mistake having really good ORM tools like Hibernate, EOF, Castor o Cayenne, I was expecting full object databinding from them... but, until now, there is nothing close to .NET databinding in the Java world)

Esteban's Blog (A Delphi Programming dedicated blog): Ad Hoc SQL vs Stored Procedures

Esteban's Blog (A Delphi Programming dedicated blog): Ad Hoc SQL vs Stored Procedures

I am happy I found this blog entry, I have been looking for a disscusion about Ad Hoc SQL vs Stored Procedures it is important to know both sides of the discussion, so that the next time it is necesary to choose, one can provide the best possible solution.

Why can't Hibernate just load objects on demand?

Today I was reading: Why can't Hibernate just load objects on demand?
I find some of its affirmations interesting (I realize this is kind of a sensitive topic, but I just don't feel that the information there is convincing enough, specially if you have used other ORM that do have distributed non-transactional lazy loading:

If Hibernate would, hidden from the developer and outside of any transaction demarcation, start random database connections and transactions, why have transaction demarcation at all?

That really is a very good question, what exactly it is so good about having transaction demarcation? (wouldn't it be better to have "automatic transactional demarcation"?) like this:

Customer newCustomer = new Customer(EcoSpace);
newCustomer.Name = "Air Software Ltd";
newCustomer.Telephone = "+44 (0)121 243 6689";

TelephoneNumber alternateTelephoneNumber = new TelephoneNumber(EcoSpace);
alternateTelephoneNumber.Name := "Home number";
alternateTelephoneNumber.Number = "+44 (0)121 999 9999";
newCustomer.ContactDetails.Add(alternateTelephoneNumber)

EcoSpace.UpdateDatabase();

Wouldn't it be better, if, as we have the Session, and the transactions...we could have an equivalent to ECO's EcoSpace?

(Important Note: I am NOT saying ECO is better than NHibernate, in fact I had to choose between the two for a project, and IMO NHibernate was a better choice, because its mapping capabilities for legacy databases are far superior, and its lower level session/transaction base API gave me more control, and HQL is IMO more powerful than OCL... but not all projects need that level of control, and... specially for new projects that do not need to interoperate with legacy apps, or that will have full control of the database ECO could be a much better alternative because of its easier to use API with automatic transactional demarcation and non-transactional lazy loading)

What happens when Hibernate opens a new database connection to load a collection, but the owning entity has been deleted meanwhile?

I guess in that case it should throw an exception... but I don't see this a justification for transaction demarcation... IMHO the same problem can happen with regular "manual session opening an closing"

(Note that this problem does not appear with the two-transaction strategy as described above [in the question Can I use two transactions in one Session?] - the single Session provides repeatable reads for entities.)

Yes, but that also means I need to have a session and transaction open during user think time...

Why even have a service layer when every object can be retrieved by simply navigating to it?

That is really a problematic question... in fact... the question is my point exactly... why should I bother having a service layer if every object can be retrieved by simply navigating to it? IMHO not having to build a service layer sound like a good thing... doesn't it?

All of this leads to no solution, because Hibernate is a service for online transaction processing (and certain kinds of batch operations) and not a "streaming objects from some persistent data store in undefined units of work"-service. Also, in addition to the n+1 selects problem, do we really need an n+1 transaction and connection problem?

So... that means... that if we want distributed non-transactional lazy loading we should build a streaming objects from some persistent data store in undefined units of work service? is that what other ORMs (like Borland ECO or Apple's EOF are? who draws the line? I know that the owners of Hibernate are free to choose, but is this decision theoretically supported? I'd like to know how...)

The solution for this issue is of course proper unit of work demarcation and design, supported by possibly an interception technique as shown in the pattern here, and/or the correct fetch technique so that all required information for a particular unit of work can be retrieved with minimum impact, best performance, and scalability.

Yes, but OpenSessionInView is only a good idea if you are building a web application.. and if you want only one transaction per request/response cycle... if you UI deviates from that... then it is no longer such a good idea...

Note: Some people still believe that this pattern creates a dependency between the presentation layer and Hibernate. It does not...

Well, then, why OpenSessionInView isn't a good idea for interactive UIs in smartclients? isn't changing form ASP.NET to WindowsForms a change on the presentation layer? so.. If i built my application to share its business logic between a WindowsForms and an ASP.NET presentation and I am going to have problems... then that means I am tied to a particular presentation layer... isn't it?

Object Relational Mapper vs Business Entity Manager

In my opinion the best two are Hibernate and EOF, I think a mix between them could create "the ultimate" Object Relational Mapper... or the ultimate Business Entity Manager...?

EOF (the best BEM?)

• General Overview
• Manual
  

Hibernate (the best ORM?)

• General Overview
• Manual
  

An interesting topic for analysis could be the limits between an Object Relational Mapper and an Business Entity Manager. Some people think that Hibernate shouldn't evolve to become more like EOF, because it should aim to do one and only one thing (be the best ORM) and other people think that it would be nice to have the services that an Business Entity Manager gives you:

• automatic connection handling
• automatic transactions handling
• multiple undo levels
• real nested transactions
• client and server objects
• distributed non-transactional lazy loading
• etc,etc
  

There are also some people that think that a Business Entity Manager is more closer to the MDA "objective", so I think it is important to take a look at (Using Borland's ECO to develop model-powered applications for .NET) an many related articles, the specially interesting thing for me about ECO is its OCL support (that can be used, for example to configure constraints that help ensuring that only consistent data is saved into the database... it is kind of a Design by Contract for the domain model)

IMO the Active Record pattern is getting too much popularity (perhaps thanks to Ruby , but I think it leads to an anemic domain model ) and Domain Model based in Business Entity Managers is not as popular (thanks to the problems in EJB1 and EJB2) but it is important to remember that EJB is not the only way to build an Business Entity Manager, there are ways to build Business Entity Managers that are a lot more lightweight and user friendly than EJB, (just investigate more about EOF and ECO)

NG-UIPAB V3 Alpha 3... UnitTesting!

Hi!
This releases has several minor bug fixes, the majority of them because I have upgraded the UnitTests for UIPAB 2.0 and that allowed me to test all the changes the UIP has suffered in my hands. This will make it easier to add new features without the fear of finding I broke something important.

The majority of the bugs fixed were related to the difference between the HybridDictionary and the new generic Dictionary<K,V> with an HybridDictionary it as right to ask for an unknown key:

if(hybridDictionaryInstance["SomeUnknownKey"]==null) {

//The SomeUnknonwKey is not in the HybridDictionary

}

But in .NET 2.0, that code throws a "Key not found" exception and I have to:

if(!genericDictionaryInstance.ContainsKey("SomeUnknownKey")) {

//The SomeUnknownKey is not in the Generic Dictionary

}

The other problem was WindowsFormViewManager.GetCurrentViews(taskId) I am sure that my choice for return type was the correct one (IDictionary<string, IList<WindowsFormView>>) but it seems to be consistent with my interpretation of the internal workings of the UIPAB

So, in the test, where it said:

Hashtable views = WindowsFormViewManager.GetCurrentViews(taskId);

Now says:

IDictionary<string, IList<WindowsFormView>> views;
views = WindowsFormViewManager.GetCurrentViews(taskId);

And, where it said:

views["name"];

it now says:

view["name"][0]

But I am not that convinced about the usability of this structure... perhaps I should simplify it in the next release. (The previous code IMO seems to handle this in an inconsistent way... some code assumes that the view is a dictionary strings and WindowsFormViews, and other code assumes that the key is a string, but the value is an IList... I guess i need to analyze this more thoughtfully