DAL stands for Data Access Layer and is often used to refer to the code that accesses the database whether or not this code is actually in its own layer. In mojoPortal the data access code is truly in its own layer and totally abstracted so that the business layer has no knowledge of the underlying database platform. DotNetNuke for example has the business and data classes all mingled and compiled into the same dll as the web site. There may be conceptual layers but that is not what I call clean separation of business logic , data access logic , and presentation logic. The mojoPortal DAL is contained entirely in mojoPortal.Data.dll and there are currently 2 versions of this dll, one for MS SQL and one for MySQL. At some point I may also create a version for PostgreSQL, and could possibly even create a version that stores data in xml files. Using the DAL approach, the code in the DAL is written specifically for a particular db platform.
The supposed benefits of OR mapping is that it saves a lot of time because you don't have to write a lot of repetitive DAL CRUD (Create, Retrieve, Delete Update) code but there is some degree of performance hit as a trade off for this convenience. I don't claim to be an expert on OR mapping, there are a lot of them out there with a lot of differences between them in the db platforms they support and in the implementation details. Most of them use xml files to map db tables to business objects and can dynamcially generate basic CRUD SQL statements for you for the dbs they support. Some of them allow you to specify stored procedures instead of using the dynamic SQL. This is important since most apps use more than just standard CRUD. For example there is complex SQL logic to implement paging and sorting in the forums of mojoPortal that cannot be achieved with simple table selects.
My reasons for staying away from OR Mappers with mojoPortal are:
- I can achieve the same time saving with a code Generator to write the standard CRUD for the DAL. I use CodeSmith Studio with custom scripts I wrote myself so the CRUD generated is exactly the code I would write. The non-standard DAL code I write by hand but the generator saves me significant time. I often use it as a starting point even if I have to modify the code extensively after its generated. In fact I use CodeSmith to generate most MS SQL Stored procedures and also to stub out my business classes.
- The code in my DALs is much more optimised for the specific db platform and gives better performance and is cleaner and easier to understand in my opinion.
- Learning to use an OR Mapper may be easier than learning multiple db platforms but many of them are very complex. There is a 400 page book for using NHibernate for example. I think using an OR Mapper would add a lot of complexity to my solution without providing significant benefits that I don't already have. I would wager that many of them have more code in them than the whole mojoPortal framework currently has.
- SQL skills are very common. OR mapping adds a grey box between the application code and the db. Chances are mojoPortal will be installed and used by companies that either have in house MS SQL or MySQL expertise. I want people who have these skills to be able to take the source code and extend it to meet their needs by seeing code they can understand readily.
I don't say that no-one should use them or that it is bad to use them but so far I'm not sold on the supposed benefits of that approach for my own work. Others may disagree with my points.