AdFactum ObjectMapper .NET Blog

Official blog of the AdFactum ObjectMapper .NET

Archive for December, 2006

New Release – ObjectMapper .NET 1.45.1129.0

Posted by Gerhard Stephan on 29th December 2006

This is a minor bug fix release for the connect method of the SqlPersister class. The connect method did not handle the password parameter in all cases and therefore the user could not always connect to the Sql Server.

That’s fixed now. I wish you a successfull new year 2007.

Cheers
Gerhard

Posted in Releases | 7 Comments »

Publication in the dotNetPro magazin

Posted by Gerhard Stephan on 19th December 2006

Today the dotNetPro magazin published an article about the AdFactum ObjectMapper .NET in their current january 2007 issue.

January 2007 issue of the dotNetPro magazin

I want to say thank you to Christian Liensberger who wrote that article. Furthermore thanks to all developers who helped me to improve the ObjectMapper .NET.

The development of the ObjectMapper .NET has just gathered way up. So stay tuned.

Hope you enjoy reading the dotNetPro.
Cheers

Gerhard

Posted in Miscellaneous | No Comments »

Attribute: [BindPropertyTo]

Posted by Gerhard Stephan on 19th December 2006

The attribute BindPropertyTo is used to bind single properties or a collection to a specifc data type. This property is always required if you want to map a property with a not specified data type – like a property that returns an interface, an abstract class or a untyped collection.

Using the [BindPropertyTo] for that cases offers you a better performance, because the ObjectMapper .NET knows the target data type for the property and does not need to evaluate it dynamically.

Examples for using the BindPropertyTo attribute are:

        private IList contacts = new ArrayList();

 

        [BindPropertyTo(typeof(Contact))]

        public IList Contacts

        {

            get { return contacts; }

            set { contacts = value; }

        }

or

        private AbstractContact contact = new Contact();

 

        [BindPropertyTo(typeof(Contact))]

        public AbstractContact Contact

        {

            get { return contact; }

            set { contact = value; }

        }

or

        private IContact contact = new Contact();

 

        [BindPropertyTo(typeof(Contact))]

        public IContact Contact

        {

            get { return contact; }

            set { contact = value; }

        }

Additionally you will find useful informations in blog entry How to do bind collections.

Posted in Attributes | No Comments »

Concepts for searching in database

Posted by Gerhard Stephan on 13th December 2006

The AdFactum ObjectMapper .NET makes it technically easy for applications to search for objects in database. Most problem I had, and what I had to learn was not how to search technically, but how to search in a clear conceptual way.

If we are talking about searching, we are talking about two issues.

  1. What to search
  2. Where to search

These two issues aren’t always easy to separate. I wrote this blog entry in order to help you to make your decision if a search condition is a "What" or a "Where".

"Where to search"
A "Where" is always a static property of the search within a search dialog. So If we not would specify any "What to search" constraints, we would get the complete content of the "Where" constraint.

Example:

  • We search within all contacts.
  • We search within all contacts who have sales within the running year.

In our application we would have two search dialogs, or at least two search areas. You see, the "Where" specifies the surrounding context of the search function.

"What to search"
A "What" is always a user defined limitation of the search result. Within the search dialog, the user has the right to change the "What" limitation for his needs.

Example:

  • I want to search contacts where surname is "Meyer"
  • I want to search contacts who are older than 30 years.

The "What" is always a user defined limitation of the search. As a result you can apply every "Where" (search scope) to any "What" (search criterias). So these two can be combined.

Consideration:
Splitting the search scope and the search criterias into distinct cases, offers you the possibility to re-use the search criterias for different use cases within your application.

How to split the search context from the search criterias
With this theoretical background I want to explain how to split the search scope and the search criterias.

    /// <summary>

    /// Interface that defines a scope for a search criteria

    /// </summary>

    public interface ISearchScope

    {

        /// <summary>

        /// Gets the search condition.

        /// </summary>

        /// <value>The search condition.</value>

        ICondition Condition

        {

            get;

        }

    }

The interface used to define a search scope is quite simple. Because a search scope is static, only a Condition must be returned that can be added to the condition of a search criteria. In praxis, the Condition returns a search condition of type ConditionList (which can contain multiple conditions).

    /// <summary>

    /// Interface that defines a search criteria

    /// </summary>

    public interface ISearchCriteria

    {

        /// <summary>

        /// Set the scope for a search criteria.

        /// </summary>

        /// <value>The Scope.</value>

        ISearchScope Scope

        {

            set;

        }

 

        /// <summary>

        /// Gets or sets the order by.

        /// </summary>

        /// <value>The order by.</value>

        OrderBy OrderBy

        {

            get;

        }

 

        /// <summary>

        /// Gets the search condition.

        /// </summary>

        /// <value>The search condition.</value>

        ICondition Condition

        {

            get;

        }

 

    }

The search criteria interface offers the possibility to set a search scope. This is used to set the "Where" Constraint of a search. A concrete implementation must use the result condition of the scope and add it to the result of the search criteria that will be returned by calling the Condition Property.

Example of a search scope that limits the search to active projects:

    /// <summary>

    /// Search criteria only works on active projects

    /// </summary>

    public class ActiveProjects : ISearchScope

    {

        /// <summary>

        /// Gets the search condition.

        /// </summary>

        /// <value>The search condition.</value>

        public ICondition Condition

        {

            get

            {

                return

                    new ConditionList(

                        new AndCondition(typeof(Project), "IsDeleted", false),

                        new Parenthesize(

                            new OrCondition(typeof(Project), "StartDate", QueryOperator.Is, null),

                            new OrCondition(typeof(Project), "StartDate", QueryOperator.LesserEqual, DateTime.Today)),

                        new Parenthesize(

                            new OrCondition(typeof(Project), "EndDate", QueryOperator.Is, null),

                            new OrCondition(typeof(Project), "EndDate", QueryOperator.GreaterEqual, DateTime.Today))

                        );

            }

        }

    }

Example of a base class that can be used to derive search criterias:

 

    /// <summary>

    /// Base class used for every search

    /// </summary>

    public class SearchCriteria : ISearchCriteria

    {

        private ISearchScope scope = null;

 

        /// <summary>

        /// Sets the scope.

        /// </summary>

        /// <value>The scope.</value>

        public ISearchScope Scope

        {

            set { scope = value; }

        }

 

        /// <summary>

        /// Gets or sets the order by.

        /// </summary>

        /// <value>The order by.</value>

        public OrderBy OrderBy

        {

            get { return null; }

        }

 

        /// <summary>

        /// Gets the search condition.

        /// </summary>

        /// <value>The search condition.</value>

        public virtual ICondition Condition

        {

            get

            {

                return scope.Condition;

            }

        }

    }

 

Example of a class that searches for projects:

    /// <summary>

    /// Project search Criterias

    /// </summary>

    public class ProjectSearchCriteria : SearchCriteria   

    {

        private string name = "";

        private DateTime startedAfter = DateTime.MinValue;

           

        /// <summary>

        /// Gets the search condition.

        /// </summary>

        /// <value>The search condition.</value>

        public override AdFactum.Data.ICondition Condition

        {

            get

            {

                ICondition result = base.Condition;

               

                if (name.Length>0)

                    result.Add(

                        new AndCondition(typeof(Project), "Name",
                            QueryOperator.Like_NoCaseSensitive, Name)

                        );

               

                if (startedAfter != DateTime.MinValue)

                    result.Add(

                        new AndCondition(typeof(Project), "StartDate",
                            QueryOperator
.GreaterEqual, StartedAfter)

                        );

                   

                return result;

            }

        }

 

        /// <summary>

        /// Gets or sets the name.

        /// </summary>

        /// <value>The name.</value>

        public string Name

        {

            get { return name; }

            set { name = value; }

        }

 

        /// <summary>

        /// Gets or sets the started after.

        /// </summary>

        /// <value>The started after.</value>

        public DateTime StartedAfter

        {

            get { return startedAfter; }

            set { startedAfter = value; }

        }

    }

Consideration of the example above:

As you can see, you can attach several search scopes to the project search criterias. Thus allows you to search within different scopes, e.g. search only in active projects or search in all projects without changing the project search criterias.

I think this is a great possibility to build complex search functionality without overloading the search criterias by context or scope changes.

Wish you all the best
Gerhard

Posted in Hint | 4 Comments »

New Release – ObjectMapper .NET 1.45.1106.1

Posted by Gerhard Stephan on 6th December 2006

The new Release covers a new special feature called Nullable Types in Visual Studio .NET.  Using Nullable Types allows you to assign NULL to value types like integer or Guids. That’s very useful when using Databases, because Value Types never existed in that paradigm.

How to declare Nullable Types? That’s pretty simple. Only put a question mark after the value type you want to make nullable.

private int? nullInt = null;
private DateTime? nullTime = null;
private Guid? nullGuid = null;

If you are using Visual Studio .NET 2003 you can work alternatively with the following declaration.

private DateTime nullTime = DateTime.MinValue;
private Guid nullGuid = Guid.Empty;

As an other feature I improved the re-use of SQL Bind Parameters specially for Oracle. And last but not least, I fixed some smaller bugs when exporting the data repository. In Detail:

  • Not all entity relation have been exported in the old version when writing the repository. 
  • Virtual Links based on Virtual Links produced wrong entity relations when writing the repository

Hope you all enjoy the new version of the ObjectMapper .NET

Wish you a merry christmas
Cheers

Gerhard

Posted in Releases | No Comments »