Geek Answers Handbook

Should a company ever know anything about its DAO?

I have a chance to introduce NHibernate into my group, using it with some new components that are being added to an outdated application. I am trying to make out a DAO template with NHibernate around me, and I am puzzled by the architectural issue.

In my fictional example, let's say I have a CarDAO and a car:

public interface CarDAO { Car FindById(int id) ... // everything else } public interface Car { ... various properties and methods }

I need to be able to convert the car to the right drive. Since this will be a very complicated operation, I need to execute a stored procedure. I don't understand where the ConvertToRightHandDrive () method should go.

It makes sense for me to put the method on Car and give it a method call on CarDAO, which will execute the stored procedure. And this is where I do not understand:

  • should the car refer to CarDAO and call CarDAO.ConvertToRightHandDrive?
  • should there be some kind of CarService level that calls CarDAO.ConvertToRightHandDrive?
  • how about injecting CarDAO using the Car method (Car.ConvertToRightHandDrive (carDAO))
  • any other option?

Perhaps this is only a religious argument, and people have different opinions about whether the Essence should have a link to its DAO (or any other DAO, for that matter). I searched StackOverflow for a while and saw some discussions on this topic; but I would be interested in the opinions of people in this particular scenario.

+4
source share
2 answers

The way I have always been told to think about this is that Entities must have as few as possible in them and that various objects must perform operations against entities. Entities themselves should not know about DAL or lose their ignorance of the data warehouse

So, in this case, a CarManager (or similar), which may have a dependency on CarDAO , should have a ChangeToRightHandDrive(Car) method.

Oh, and another advantage of having CarManager complex operations is that you don’t rely on stored procedures - this is almost certainly a religious problem, but I prefer to have all the logic in my code rather than relying on SP (there are a few exceptions, but usually only around large sets). This means that if you switched to another DAL (say XML), you will not need to re-embed your SP in your DAL/DAO - otherwise, you will get business logic embedded in your DAL.

+1
source

My opinion is that Car should not know CarDAO . This will simplify your domain model and allow you to change the front end without affecting the Car class.

If you need to call a stored procedure to convert the car to the right drive, I like the CarDAO.ConvertToRightHandDrive(Car car) option, and then use something like the CarService class to hide the dependency on CarDAO from any callers (i.e. the class CarService would have an identical method that simply redirected the call to CarDAO ).

As you mentioned, people definitely will not agree to this type of thing, but it is always worthwhile to carefully consider dependencies and relationships before you start to crack.

+1
source

More articles:


All Articles