iBatis.NET DataMapper 1.6.1 does not support default parameters in stored procedures

iBatis.Net DataMapper is our de facto standard for implementing persistence in .NET applications. The framework works well with an object-oriented domain model and relational data store.

Today, we stumbled upon a bug in the latest production release of iBatis.Net DataMapper. A new parameter was added to the existing stored procedure and although this parameter came with a default value, the application threw the following exception: 
"Specified argument was out of the range of valid values. Parameter name: index" from IBatisNet.DataMapper.Configuration.ParameterMapping.ParameterPropertyCollection.get_Item.

One way to work around this issue is to replace the original procedure configuration:

<statements>
  <procedure id="OurStoredProcedure" parameterMap="OurStoredProcedure_Parameters" >
    up_YourStoredProcedure
  </procedure>
</statements>

</parameterMaps> 
   <parameterMap id="OurStoredProcedure_Parameters" class="OurParametersClass">
     <parameter property="Value1"/>
     <parameter property="Value2"/>
   </parameterMap>
<parameterMaps>

with a dynamic statement:

<statements>
  <statement id="OurStoredProcedure" parameterClass="OurParametersClass" >
    EXEC up_OurStoredProcedure #Value1#, #Value2#
  </statement>
</statements>

Happy coding!

September book review: Design Patterns

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Design Patterns: Elements of Reusable Object-Oriented Software

Design Patterns is one of my favourite technical books of all time. It has been highly influential on my understanding of object-oriented design and software engineering principles in general. It helped me hone my skills as a software architect early in my career and now serves as a reference material for many of my training sessions.

This book catalogs 23 commonly used design patterns:

  • Creational
    Abstract Factory, Builder, Factory Method, Prototype, and Singleton
  • Structural
    Adapter, Bridge, Composite, Decorator, Facade, Flyweight, and Proxy
  • Behavioral
    Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, and Visitor

For each pattern, the authors describe the design problem addressed, the circumstances in which the pattern is applicable, and the consequences of using the pattern to solve the problem.  Each pattern is supplied with relevant UML diagrams and simple C++ examples.

As design patterns are becoming mainstream, more and more books are published on this subject. You can easily find resources with examples in C#, Java, VB.NET, and other programming languages. My recommendation is to read the original book first.  I find it less prescriptive and more thought-provoking, leaving you with options for implementing design patterns in practice. Do not fall into the trap of thinking about patterns as prescriptive solutions to common design problems. Instead, think about each pattern as a multiple-step journey. At each step, you can and should review your design problem at hand as well as the trade-offs associated with using the pattern. You can stop, move to the next step, or to continue with implementation in a different direction. The choice is yours.

This is a must-read book for any software engineer and is highly recommended for first-line managers. As a minimum, it will allow you to speak with your team at a higher level of design abstraction.

To find more information about this book, click here. Happy reading!

March book review: Agile Principles, Patterns, and Practices in C#

Once again, it is time for our monthly book review.

Robert C. Martin and Micah Martin
Agile Principles, Patterns, and Practices in C#

A well written book on the subject of software design. The authors describe fundamental object-oriented principles, dig into a few design patterns, and even touch on agile methods while providing easy-to-follow examples in C#. Reading this book is like spending a day working together with a team of software developers where you can observe their development practices first hand.

While this book is not likely to become one of the classical books on object-oriented design, it is very practical and I recommend it to every .NET developer. For advanced readers, I highly recommend Robert Martin's original articles on OOP from 1990's. They are as valuable today as they were at the time when they were written.

Happy reading!

February book review: Domain Driven Design

Eric Evans
Domain Driven Design

I met Eric Evans in August of 2004, when his book had just came out and he was in Twin Cities at the Object Technology User Group (OTUG) talking about Ubiquitous Language, a language used by all team members to describe the domain model. I was very impressed with Eric's presentation. In very simple terms, he was able to find and explain the essence of what is often missing in domain implementations focused too much on technology.

You will not be disappointed with Eric's book. It describes patterns on how to explore a complex business domain and express it with a comprehensible software model. These patterns help me focus on central business problems while keeping the overall design of the systems understandable and manageable.

This is a must-read book for a business application designer and developer. Happy reading!

Welcome to ModelBlog

Thank you for visiting ModelBlog. We hope the time you spend with us will be both entertaining and worth your while. Have fun!

Authors

Search

Archive

Tags