There's been a lot of discussion recently about the Object to Relational mapping problem, which is a serious one. This Clemens Vasters blog entry summarizes it best:
You are an ignorant stupid moron. Try pulling your head out of your ass.
Hey Curt: would you care to back that up with any solid real-world analysis of why a domain model is in fact ābetterā?
No; I thought not.
Rails does this kind of thing.
The ActiveRecord pattern is also great for auto-CRUD.
VB6 Enterprise (possibly Professional) can also do this, though it uses āexclamation markā syntax, rather than just a dot.
Personally I used it once and forgot about it, but it is there.
Shouldnāt:
ds.Customers.Customer(1).FirstName
be:
ds.Customers(1).FirstName
Hi,
What you are talking about is a āsimpleā GUI where the mapping between objects and tables is fairly evident (Customer.FistName - Field āFirstNameā in table āCustomerā).
For these kind of applications, OOP (Object-Oriented Programming) is perhaps not necessary. And some object languages/IDE (Delphi for instance), let you directly link graphical components to database fields.
But if you have a complex business logic, with several concepts that do not match directly in the database, if you want to reduce the coupling between the different parts of your project, then OOP is a must.
Re: āif you have a complex business logic, with several concepts that do not match directly in the database, if you want to reduce the coupling between the different parts of your project, then OOP is a must.ā
Why is this? I keep hearing the buzzphrase ācouplingā, but actual examples are either not applicable to the biz domain, or make poor change-pattern assumptions.
OOP lacks any native ties to set theory, and I think this is the problem. OO is based on physical decomposition, but biz apps often deal with intellectual property decomposition, in which sets are better than aggregation. Sets can be hard to get your head around, but once you do you see the world differently.
Actually, using a higher-level language can deal with a LOT of the pain. Iāve recently been working on a pair of projectsāone at work, one at homeāwhich both implement database-backed web sites (nothing groundbreaking, just useful stuff). Iāve managed to use macros to write all the tedious mapping code for me, and even have some escape hatches for when the defaults arenāt what I want. A single piece of code creates the object, associates it with the database, creates an accessor function for the web page templating language and creates a predicate function for the templating language.
Several of my database tables use inheritance, so the classes do the same thing. It all Just Works, and adding a new class takes less than a minute. If anything, itās become rather boringāboring in a good way:-)
Actually, Gemstone Smalltalk has had almost that exact same notation for years (well over a decade). Screw OR mapping, get a OODBMS.
Uh Oh, somebody doesnāt understand OO Programming!
I think that like many who have lost the oop faith you miss a critical aspect of oop design that is rarely mentioned. Oop is largely an outgrown of simulation programs that sought to model a real situation through decomposition of the problem into individually comprehensible features. The system was then supposed to emerge from these pieces. This works great when you want to run a physics expirement in your silicon or if you want an appearently intellegent game universe but for 99% of business apps, embedded apps, stuff people get paid for the problem domain is precicly the reverse of that. Usually the overall behvaior of the system is known beforehand, if your accounting code demonstraits emergent behavior you probably have to explain yourself to the SEC. In order to stop this runaway problem most oop developers consciously restrict the expressiveness of thier code to combat the problem.
The real solution is to abandon oop when it is counter productive.
What do you think about the LINQ stuff?
I for one think that, for the first time, it will make sense for me to have a data layer.
In tha past I have avoided them because they tend to load too much data that I donāt actually need. But with LINQ, it looks like I can create lightweight classes without all the headache.
I work at the company linked with my name, so take that as a disclaimer, but it has a product that does what you ask for in this post. Given a schema definition (created by dragging and dropping tables into a designer window within VS), you automatically get a data access layer that is strongly typed and easily accessed.
It seems the winds have changed since this post was written in 2004 and most people are in love with O/R mapping, but I still think that typed datasets are the way to go.
Datasets lose for me due to their enormous memory footprint. Itās worth the extra effort for the data mapping to save RAM (in my scenario).
Hey, Russell Garnerā¦ If you actually want a response you can email me at my posted email address. Making your own post over a year after mine and expecting me to answer you is indicative of your limitations. In the meantime, you and Jeff should adopt the following adage: Donāt criticise what you donāt understand.
I disagree completely to the statement that objects and object oriented designs are not suitable for business software. In fact, it is business needs that force us to use object oriented architecture in the first place.
Data in a database is just that. Data. It does not have any business rules or logic attached to it. And it is supposed to be that way. An RDBMS or database system is just a repositery for data. It is not supposed to contain business rules and logic.
While building software which uses business logic and rules, we combine the data from the database and enhance it with business rules and logic by encapsulating the data into business objects. These business objects model the business that has to be modeled. And when used properly, these business objects can prevent bad/illogical data from creeping into the database.
For how to do this, read the book Expert C# 2005 Business Objects by Rockford Lhotka or Expert VB 2005 Business Objects by Rockford Lhotka (if you prefer VB) or visit his website www.lhotka.net.
Thank you
Cosmic Ovungal
Cosmic, you are 100%, completely wrong. A RDBMS is not a repository for data, it is supposed to have business rules and logic. This mysql3 attitude that inexperienced developers have been getting lately is terrible. Your database management system should manage your data. It almost seems like thatās the exact purpose they were designed for or something. Maybe thatās why its right there in the name?
Putting data logic and rules into your code not only makes things far more difficult (and in fact is what creates the so called object relational mismatch), but it also means you have to duplicate that code in every app that touches your data for no reason, and thus artificially limits you to using one language so you can reuse that data logic easily.
Harold, not all data logic is best left to the DB. Not a perfect example, but consider a list of employees ā the bigger the set of records, the faster it is to sort the list in Java than via SQL.
While it takes some sematics out of SQL and pops into into a single language, there are times when youāre want to do such violations for performanceās sake.
(Disclaimer: this comment is based on my experience with .NET/SQL, and may not be applicable to other languages/databases)
Harold,
Putting data logic and rules into code does not imply that the logic must be duplicated in every subsequent application. More precisely, it DOES mean you need to reuse that logic in the new application, whether as uncompiled code or a compiled DLL.
Putting logic in code rather than the database gives the advantage of allowing new interfaces to the same data to implement different business rules (within reason!) with less risk of impacting on previous interfaces. This is especially the case where the new interface has stricter data requirements and isnāt concerned with subsequent reads matching its validation rules.
Databases can mitigate the risk of changes to one consumer impacting others, but I hope we can agree that the options (versioned stored procedures or pollution of the database schema/logic with information about the consumer) arenāt nice.
-Cheers