Showing messages 1 through 7 of 7.

• Regarding the Service-Interface
  2006-05-16 14:47:49 tomy [Reply | View]
  
  IMHO the Service-Interface should not expose the setTasksDao()-Method.
  
  This method is purely an implementation detail of a specific ServiceImpl-Class and not something a client of the Service should need to know.
  
  Just my 2c

• jdbc code error?
  2006-05-15 14:59:32 lumpynose [Reply | View]
  
  Isn't there a bug in the finally block where it's closing things down? It seems to me if the rs.close() throws an exception then the pstmt.close() and con.close() will never be called:
  [code]
  } finally {
  try {
  rs.close();
  pstmt.close();
  con.close();
  } catch (SQLException e1) {
  System.out.println(e1);
  }
  }
  [/code]
• jdbc code error?
  2006-05-26 06:57:50 misuasm [Reply | View]
  
  lumpynose:
  Indeed, the finally block contains errors. The safe way would be to wrap each of the rs.close()/ps.close()/con.colse() with a try/catch block . The smart way would be to use Spring template classes :) The big advantage of using Spring is that you never have to worry about opening/closing connections/prepared statements/result sets. Spring does it all for you.
  
  
  
  srinathv77:
  I am sure lumpynose undestood what the author was trying to say since he observed the error.
• jdbc code error?
  2006-05-18 10:34:58 srinathv77 [Reply | View]
  
  Try to understand what the Author is explaining!

• Inject?
  2006-05-09 11:54:26 liminal [Reply | View]
  
  What's with all this "injecting"? What does this word mean in software? I've never seen it used before... Does it have a specific software-related meaning, or does it just refer to setting a value somewhere?
• Inject?
  2006-05-11 10:18:39 lumpynose [Reply | View]
  
  Another way to look at injecting is that it's an additional step in decoupling.
  
  We've learned that you shouldn't say
  
  ArrayList arrayList = new ArrayList();
  
  but should instead say
  
  List list = new ArrayList();
  
  And then even better, is to use a factory
  
  List list = ListManager.makeList();
  
  Injection is the next step in the progression; you have a private List variable in your class and setter for it in your class and you never set the list variable in your code (except in the setter), and someone calls the setter with an object that implements List. The framework is what calls the setter, and it's specified what to call it with via an xml config file typically.
• Inject?
  2006-05-09 14:46:19 whartung [Reply | View]
  
  

  The Inversion of Control (IoC) frameworks (such as Spring) essentially provide generic class factories and then use some mechanism (typically XML files) to "wire" object dependencies in order to remove such "wiring" from your code.

  The framework resolves the configured dependencies at runtime for you, rather than hardcoding them yourself.

  The technique is called "injection" and, yes, it's simply setting a property in a class.

  To leverage the provided example, in this case the JDBC methods call a "getConnection" routine in order to acquire a JDBC connection. Using an IoC framework, rather than using getConnection, you'd simply have a Connection member variable. When you went to get a new instance of your class, rather than calling "new YourClass", you'd ask the IoC framework for it instead.

  The IoC framework would see that you have a Connection (because you configured it that way), and when you got your object from the framework, the Connection member variable would come "pre-populated". So the class doesn't need to know how to get a Connection, as one is "injected" in to it when the class is created.

  The competing techniques are "contructor injection" and "setter injection", meaning that the properties of an object are set either via the constructor or simply a setter.

  The whole goal around IoC frameworks is to keep the objects as simple as possible by pulling the dependencies out of them. By relying on a factory to create your objects, the factory assumes the burden of knowing how to create the different resources (like Connections). Combine this with using Interfaces instead of Objects, and it makes unit testing much easier.

  In this case, you could reconfigure the IoC framework to provide your class with a "fake Connection", used only for testing. If your class has a "hard coded" getConnection method, then you'd have to change the class to get another kind of Connection. Or, you wouldn't even have to use the framework at all. Simply do "new YourClass", call it's "setConnection" method, and then run the logic. The class itself stays the same for both the application and the unit test.

  That's just a simple example of the basics of an IoC framework. The modern ones take the simple concept and add on to it in many ways.