AutoPoco 0.4 released - features features features

Published on 2010-4-15

What's that? I skipped a number? Actually I didn't, but 0.3 wasn't particularly major so making a blog entry seemed a bit redundant :)

What have I added? Glad you asked:

Method Invocation

During configuration, you can now set up data sources for parameters of methods, just pass in raw values or just call a method with no arguments.

It's all been done in a strongly-typed manner to fit in with the rest of AutoPoco.

                x.Include<SimpleMethodClass>()
                    .Invoke(c => c.SetSomething(
                        Use.Source<String, RandomStringSource>(5, 10),
                        Use.Source<String, LastNameSource>()))
                    .Invoke(c => c.DoSomething());

Obviously this needs a brother to override this configuration at the time of object creation, and that looks something like this:

            IList<SimpleMethodClass> items = mSession.List<SimpleMethodClass>(100)
                    .Invoke(x => x.SetSomething("Something"))   
                .Get();

And this will call SetSomething on all the created objects with the argument "Something" - this set of functionality is for those who don't have accessible setters on public properties but still wish to invoke them. The alternative was to start proxying around the objects and demanding that properties be virtual - but unless somebody says otherwise, I think that's a bit heavyweight for this sort of library.

Improved Convention Support

Conventions have been baked into AutoPoco from the start, but weren't fleshed out until this iteration, they can be used to match types of property/field, or match the names of properties/fields (or both) and apply rules to them without any knowledge of the specific type being configured.

This is useful for those with multiple projections of their domain, which follow naming conventions throughout the project.

    public class EmailAddressPropertyConvention : ITypePropertyConvention
    {
        public void Apply(ITypePropertyConventionContext context)
        {
            context.SetSource<EmailAddressSource>();
        }

        public void SpecifyRequirements(ITypeMemberConventionRequirements requirements)
        {
            requirements.Name(x => String.Compare(x, "EmailAddress", true) == 0);
            requirements.Type(x => x == typeof(String));
        }
    }

This convention will match any property of type string called EmailAddress and apply the EmailAddressSource to it.

Inheritance

This was more complicated to deal with, and I expect to be writing a couple of quick blog entries detailing some of the gotchas encountered when writing the code for this, as googling didn't really provide the answers I was looking for (My first port of call for all problems)

The gist of it, is that if you have an interface with a property, and you define a rule for that property, then any class that implements that property will also inherit that rule (the same goes for base classes and their properties).

If a rule is defined for that specific derived class, then it will override the rule provided by the interface or base class. The only thing I haven't expliclty included in this is open generics, because they're a bit more tricky to come up with an elegant solution for.

Consider the following class structure:

    public interface ISimpleInterface
    {
        string InterfaceValue
        {
            get;
            set;
        }

        string OtherInterfaceValue
        {
            get;
            set;
        }
    }

    public class SimpleBaseClass : ISimpleInterface
    {
        public string BaseProperty
        {
            get;
            set;
        }

        public virtual string BaseVirtualProperty
        {
            get;
            set;
        }
    
        public string InterfaceValue
        {
	      set;
          get;
        }
        
        public string OtherInterfaceValue
        {
            get;
            set;
        }
    }

    public class SimpleDerivedClass : SimpleBaseClass, ISimpleInterface
    {
        public string Name
        {
            get;
            set;
        }

        public override string BaseVirtualProperty
        {
            get;
            set;
        }
    }

With the following configuration

                x.Include<ISimpleInterface>()
                    .Setup(c => c.InterfaceValue).Value("InterfaceValue - ISimpleInterface")
                    .Setup(c=>c.OtherInterfaceValue).Value("OtherInterfaceValue - ISimpleInterface");
                 x.Include<SimpleBaseClass>()
                    .Setup(c => c.BaseProperty).Value("BaseProperty - SimpleBaseClass")
                    .Setup(c => c.BaseVirtualProperty).Value("BaseVirtualProperty - SimpleBaseClass");
                x.Include<SimpleDerivedClass>()
                    .Setup(c => c.Name).Value("OtherTest")
                    .Setup(c => c.BaseVirtualProperty).Value("BaseVirtualProperty - SimpleDerivedClass")
                    .Setup(c => c.OtherInterfaceValue).Value("OtherInterfaceValue - SimpleDerivedClass");

Requesting a SimpleBaseClass, we get

Requesting a SimpleDerivedClass, we get

It looks a bit complicated up front, but it makes sense if you think about it and that's what matters (the functionality is there if you need it, if you don't need it then you don't need to worry about it).

More data sources

I was expecting to have to do these myself, along with a load of standard property/field conventions - but I had an e-mail from Khalid Abuhakme letting me know he'd created a fork with some standard data sources in them.

I have pulled them through and now our list of data sources looks something like this:

We'll end up with a lot more of these for sure, and still need a more customisable aspect to some of the default ones, but if anybody else wants to contribute then feel free, as adding conventions and data sources is what will make AutoPoco really useful.

This used to ask if you wanted to hire me

But chances are I'm not available, as I'm busy shipping stuff.

Drop me an e-mail anyway, as I like interesting problems.

Get in touch

blog comments powered by Disqus