How can I design a Java web application without an ORM and without embedded SQL [closed]

Answer 1

Primary driver: less overall code to manage/maintain

Answer 2

If all I get from my ORM is to save me from the need to maintain stored procedures then that is good enough for me.

However there's much more in that an ORM allows us be free of the hostage-like grip database schemas impose on the design of our code. Things are much simpler when I can model my code exactly like the real world, and I can still do this with a (good) ORM which helps (and hides) the mapping of a potential unsightly legacy db with terrible naming conventions into a structure that means something and not care about redundant code like this everywhere:

using (SqlWrapper sql = SqlWrapper.Create(WrapperConnectionType.ShopNet, "sStore_InsertUpdate_v4"))
            {
                sql.AddParameter("StoreId", StoreId);
                sql.AddParameter("StoreName", StoreName);
                sql.AddParameter("Region", Region);
                sql.AddParameter("PostCode", PostCode);
                sql.AddParameter("Tel", Tel);
                sql.AddParameter("Email", Email);
                sql.AddParameter("RegionId", RegionId);
                sql.AddParameter("MapImage", MapImage);
                sql.AddParameter("ShopImage", ShopImage);
                sql.AddParameter("Visible", Visible ? 'Y' : 'N');
                sql.AddParameter("TazEnabled", TasEnabled ? 'Y' : 'N');
                sql.AddParameter("Latitude", Latitude);
                sql.AddParameter("Longitude", Longitude);
                sql.AddParameter("StoreOpeningDate", OpeningDate);
                sql.AddParameter("CustomerNo", CustomerNo);
                sql.AddParameter("ReserveAtStoreEnabled", RasEnabled);
                sql.AddParameter("OpeningHoursId", OpeningHours.Id);
                sql.AddParameter("AddressLine1", AddressLine1);
                sql.AddParameter("AddressLine2", AddressLine2);
                sql.AddParameter("City", City);
                sql.AddParameter("District", District);
                sql.AddParameter("County", County);
                sql.AddParameter("CountryCode", CountryCode);
                sql.AddParameter("GoogleCategories", GoogleCategories);
                sql.AddParameter("GooglePlacesEnabled", GooglePlacesEnabled);
                sql.AddParameter("ManagerName", ManagerName);
                sql.AddParameter("MapZoomLevel", MapZoomLevel);
                sql.AddParameter("IpAddress", IpAddress);
                sql.AddParameter("FlibbleEnabled", FlibbleEnabled);
                sql.AddParameter("RegionalManager", RegionalManagerId);
                sql.AddParameter("ShutlLogin", ShutlLogin);
                sql.AddParameter("ShutlPassword", ShutlPassword);
                sql.Execute();
            }

and lets eradicate (but not forget) these type of battles:

System.IndexOutOfRangeException
at System.Data.SqlClient.SqlDataReader.GetOrdinal(String name)

The argument for me doesn't have to be any more complicated than that, I get a couple of nice things and something awful is taken away. Nuff said, Next!

No one is arguing that an ORM is a 100% replacement for everything traditional. It won't be a great tool for writing complex reports, for that use SPs and views, and use NHibernate to call them natively and map them automatically to your c# entities. Great, still all the power of SQL and no crappy mapping code.

Be gone into the darkness ye storer of 0s & 1s and come hither ye light of wholesome c# weltanschauung.

Answer 3

In my experience with NHibernate it's a bit like Visual Basic: it makes easy problems really easy, but it also makes anything harder than that really hard or even completely impossible.

The basic idea is that ORM avoids having to write persistence code. There is a lot of duplication in such code, so it's very tempting to make that code generic, rather than specific to a particular business layer, and re-use it across projects. So far so good. For simple object hierarchies and business requirements this actually works really well. If your database changes, yes, you do have to change the ORM mapping files, but that's usually quite simple and you only have to make the change in one place - much easier than changing code that accesses the database.

The problem is that as your database and requirements get more complex the ORM finds it increasingly hard to keep up. So the ORM gets more and more complex. It also takes shortcuts, doing some things inefficiently, because it just isn't smart enough to figure out how to do it efficiently in all cases. What's more, because the whole idea is that it works transparently, you often can't see these performance problems until they become bad enough to affect the user experience. A related problem is that bugs are much harder to find, because you just don't know what's going on inside the ORM unless you debug it. (Yes, I've had to step through NHibernate code and it's no picnic!)

So you start bypassing the ORM for some things and use SQL directly instead. Of course, you then have to make that code work with the code that does use the ORM, which is more work. You end up writing code to load and save some objects manually and to somehow work that into the ORM code. Eventually you start wondering if the ORM is creating more work for you than it's saving - not to mention the performance and bug hunting headaches.

So if you're writing a very simple application, the kind you find in a tutorial, ORM will do a good job. If it's more complex than that then I think it's not worth it. Of course, for a simple application the absolute amount of time saved will be small as well. My conclusion: just don't bother with ORM. ORM is the path that leads to the dark side.

Answer 4

I realize this question was posted a while ago, but I've wondered the same thing as johnny. I've seen Hibernate used on several large projects by intelligent people, and in every case, it was an unmitigated disaster. In my experience, the single most complicated and performance impacting area of most enterprise applications is between business layer and the database layer. This is part of why we add a data access layer to try to encapsulate the database interactions into manageable chunks.

The biggest arguments I've seen to use ORM are that they "reduce hand written code" and provide an abstraction layer that separates business logic from the data access. I assert that neither of these are true in practice except in very simple cases.

To make Hibernate (and most other ORM tools) work, we either create a hibernate mapping file which documents all the database and object interactions, or we use annotations to document the same relationships. In one case we moved our code to an xml configuration file that is harder to test, yet no less complex. In the other, we distribute the logic of how to interact with the database all over the domain model. The point is, while we've written less actual "code", moving code to configuration files or annotations != "less code". It simply moves the complexity from the code, where we can control it directly and mitigate it, to a third party tool with far less control.

The ORM abstraction layer that is supposed to separate the business/domain layer from the database layer tends to have more subtle effects that counteract this "separation". How many projects have you seen where the ORM layer affects the design of the object model and/or the database in a way that would be considered less than ideal? To use a poor physics analogy, assume your business layer, ORM layer, and database layer all have mass. The mere existence of the ORM layer between the other to tends exert a force that changes and warps the other layers. Have you had to introduce a primary key object that doesn't quite fit in your business model because the ORM layer needed it? Have you had to adjust your database structure to accommodate a particularly complex object graph model because the ORM tool can't handle it otherwise? Taken to extremes, the presence of the ORM layer can warp the entire perspective of how database interactions should work. Instead of a service layer that handles persisting object graphs, it can devolve into creating individual data access layer objects for each domain objects, as if they live in isolation. I've seen all these scenarios in varying degrees. Perhaps it's inexperience with the ORM toolset. Perhaps it's a bad database structure. I doubt it. Everything I've seen points to the ORM solution being inadequate.

If you accept my assertion that the data access layer is one of complexity, highly prone to performance bottlenecks, why should I consider adding in a tool that doesn't achieve it's objectives of less code and separation, and at the same time negatively affecting the structure of the other layers of my application?

Answer 5

I responded thoroughly to the answer by @Marcelo Cantos however I will summurize the main benefits of using an ORM.

Persistence Ignorance (PI) and Domain Drive Design (DDD)

A ORM lends itself perfectly to both of these overall design patterns. For correct object orientated design you will work with hierarchical and polymorphic objects for expressing how data flows inside your application. With a good design you will frequently strive for POCO objects (plain old C/C# objects, I've seen other definitions of this word) because if I have a Person that has a List I should have just that. I shouldn't have a DataTable of persons and a DataTable of addresses that I somehow force to work with my application. Along with that I shouldn't need to tie tons of database specific logic to my objects, why should the FirstName field of my person need to be have something like [ColumnName("First_Name")] [Length(255)] [DataType(Types.Nvarchar)] or any other assortment of crazy attributes or code that defines how many database exists forced into my domain design?

Less Hand Written Code

There is a substantial reduction in the number of lines of code written when you remove the need to write an Select, Insert, Update and Delete statement for every single object in your application to save it to the database. This leaves you with only the need to write queries that mean something. Also many ORMs (like NHibernate) will include a language that is layered on top of SQL which is more defined to interact with and can be less syntactically filled of hoops.

The time this shows up fullest is consider an application that has a UserTable that is linked to every single object and for some reason you HAVE to change the primary key name or type. At this point you will potentially need to alter every single stored procedure in the database where with a correctly implemented ORM solution you will only need to alter a few configuration mappings (or possibly none) and it's done.

Answer 6

1 advantage you get is that your data layer is separated from the object layer, so when you have multiple applications/projects dependent on that layer you change it once in the ORM and all applications/projects that reference the object layer don't have to change, where as without it you would have to make changes in all projects.