Jonathan Crossland's Talkware

Although .NET Reflecton offers a decent look at the Types you build, it is pretty generic in its offering. For example, it does not yet provide us with capabilities to control and secure how Reflection can inspect our Types. If you do not want a Type to be Instantiated via Reflection, or if you would like to restrict certain Types from being visible at all. Further there is no idea for extension or change. One cannot simply plug into Reflection and override behaviour.

High abstractions and higher flexibility

Many more wrappers are needed, at a higher level, which would sit on top of .NET Reflection. For example, architectural dependencies. Agile mechanisms, if code had enough metadata attached, one could alter the code via reflection/refactoring in a much more dynamic way. Consider the following two web service methods in two different companies.

  public class PersonService
    {
        public void AddPerson(string lastname, string firstname, 
            string birthdate)
        {
        }
    }

    public class PersonWebService
    {
        public void AddNew(string firstname, string surname)
        {
        }
    }

You can see that they are completely different contracts. Interface and contract speaking they are like apples and sand. However, to your mapping, calculating, schema, metadata, tagging and understanding brain, its the same thing.

What we need, is to remove ourselves from Contracts to something more like guidelines.

  public class PersonService
    {
        [Operation(Schema:Person, "Add")]
        public void AddPerson([schema(LastName)]string lastname, 
             [schema(FirstName)]string firstname, 
             [schema(DateOfBirth)] string birthdate)
        {
        }
    }

    public class PersonWebService
    {
        [Operation(Schema:Person, "Add")]
        public void AddNew([schema(FirstName)]string firstname, 
             [schema(LastName)]string surname)
        {
        }
    }

Tags: design patterns, frameworks, reflection, metadata

Not sure if there is a Design Pattern relating to this kind of need in another pattern catalogue, but it seemed simple enough to reverse the GOF composite. A class with a collection of leaves, that iterate, recurse its way up to the root. This needs work in terms of combining or actually making a variation on the composite. I think that this is perhaps only a .1 degree of separation.

Problem

You have a list of Items, that may or may not be related. There may be 1 or more trees. You have a bag of unsorted or related objects as a signle array. You need to maintain a complete list of leaves, but also need the relationship/heirarchy to become apparent. You want to express the heirarchy in a Composite Pattern, but it would exclude certain leaves has it has no part in the particular root that the composite gets built on.

Context

You need a collection of leaves, from across the composite tree. You need to have access to the parent and/or recurse to the root.

Types are stripped from its branches.

 

Structure

A class that works with a collection of leaf classes, that each point to it's parent. In effect a composite in reverse. Keep all the leaf objects in a collection and build the heirarchy from the bottom up.




One of the main reasons behind this is multiple paths to a set endpoint. The root becomes the set endpoint where by we can plot a course from a leaf. The Leaf though is where we start from and full knowledge of all leaves should be known at the outset. 

By adding a Parent on the Composite (GoF), you can achieve a similar result, but you will not have a flat list of leaves.

Tags: design patterns, composite, reverse composite

Run VS.NET as Administrator on Vista.

Export your settings using Tools | Import and Export Settings, don't let another windows reinstall take it all away from you.

Get Regionerate
- but make sure you use the "Remove All regions" command, before trying to apply others. It wont replace your existing regions.

Get Studio Tools, for File manager and the tear off editor.

Download Dev /efor - not sure about the name, but it works nicely.

Snippet Editor, useful, for changing the way the existing snippets work, as well as new ones.

Carl J has a large list of add-ins.

Tags:

It is amazing how these sorts of tools divide opinion.
I usually blog about technology, especially framework oriented things, but I have been thinking a lot about business again. How can it work for business.

For example, a company I have here in my midst, Oxford Creative, arose from building sites for the car manufacturer Seat. (They are searching for clients, so get on board quickly, as they are a small but effective team.)

I have been talking about twitter and many of my friends do not see the point.

But twitter, is less evasive, more rapid, more dynamic than any other social media tool.
I do not get hounded by it. I switch it off, its off. I switch it on, I have access to some great minds.

I found this How To Use Twitter Effectively for Business and Advocacy, which says a lot about its power, amongst many other posts, which have been floating around twittersphere.

I use it, because I can meet some interesting people, like @unclebobmartin, and @kentbeck, @bigballofmudd (Brian Foote). I like twitter because its less intrusive than phones, emails and facebook, but its powerful enough to communicate.

Tags: twitter, blogging, social media

Eventually Interfaces will be replaced with magnets!

Tags: frameworks, object-oriented, design patterns

In The Every Project Framework - Part 1, I spoke of partitioning, and abstracting structure and infrastructure. Now Let's talk about how we do that.

Over the last decade, the most prolific and available Architectural Pattern introduced and adopted by business developers is the Layers pattern. Call it by another name, but the concept is around everywhere. Most enterprise systems have open or closed Layers. They have many names, but Data Access Layer, Business Layer and so on, are often used. This a good thing towards raising the level of abstraction, increasing the infrastructure and providing more structure. However, having layers, does not automatically mean your application is on a good footing.

Raising the bar

If you are very skeptical, read the 'Why' section below first.

What do you think of your objects? How do you think of them? Are they transportation, containers, db table wrappers or other? Majority of business applications I see, have objects as a 1 to 1 mapping to a database table and it effectively is a container for a row of data. Some then wrap it into a collection of these rows and you have a table. Is that really what you need? is that efficient and good practice? Does it raise the bar high enough?

The first thing to say is that wrapping your table into an object is not entirely bad, as it is a level of abstraction away from the table.
However, if its at the highest level of abstraction you go to, then you will still have miles of code that you need to place elsewhere. Code such as Context, Security, Permissions, work flow and so on. If you manage all of your Types as a 1 to 1 mapping to the database tables, are you not merely writing code against the database?

If its UI (form) accessing and using -> the DataType Person, then your level of abstraction to the data is almost zero. You have abstracted the concept of a database table and replaced it with a more crude version, which you are populating.

Then the relationships and structure between all these singular Types will slowly come together within your UI, behind your button, in some method of some obscure class. Instead, the singular classes should be a little more structured and the bar should be raised higher, providing your UI with more closer, ready and easier to use objects.

To repeat in more a programmatic way, consider a table named Person.

If you have your UI --> Types --> Table

effectively you have abstracted a Row and Column concept away from the UI and replaced it with a PersonType and a PersonTypeCollection.
That means the UI, must understand how to deal with these Types.

To raise the bar, you would have more abstractions between UI and database
perhaps more like so

UI --> PersonCompositeType --> transaction(PersonDataType1/PersonDataType2) --> Table1/Table2

So PersonCompositeType is at much high level.

Please note:I am not saying that your architecture must look exactly like this, what I am suggesting is that more levels of abstraction can be achieved between the UI and your 1 to 1 mapped Type, that is so commonly found.

Why?

Have you ever had the following in your last or current project?

The UI is a lot more work than writing the "engine" or "business layers"!
Well of course it is, because the level of abstraction for the business layer is so low.

Your project starts quickly, progress seems to be made at speed, and then it slows right, right down....
It would, because, laying out database tables, getting your SQL and business objects in a 1 to 1 mapping is easy. Tying these low level abstraction together into a working application is harder.

Are you using a workflow engine? Are you using a business rules engine? Do you have isolated, stateless services? Do you have wrappers, commands, actions?
If not, then all the workflow, business rules, services are tucked away, most likely in your user interface. If you don't think you need these things, your large projects are most likely failing, running late and/or getting harder and harder to maintain.

Closing thoughts

If you think in "the ways of frameworks". Not as a framework that will be released to the world. Not as a time consuming lets focus on the framework, but rather build it, partition it and expand it within the project, your application will benefit from having more structure and more infrastructure.

Even having one of those is vastly beneficial. That is why a company with their own libraries (infrastructure), can get an application up quicker, even if its not a framework. One or both infrastructure and structure is vital for reuse and time to market. Yet, there is very little training going on at university, or courses in this area.

We should be training developers from their earliest years in software to think about reuse, to understand patterns, and putting rudimentary frameworks together.

Don't let the fact, that there are no perfect frameworks out there, lure you into thinking frameworks are bad. They are just diamonds in the rough. Most importantly, the "good" aspects of frameworks can be used within your application to high rewards. But how do you do it? -- stay tuned...

Tags: frameworks, design patterns, methodology

In The Every Project Framework - Introduction, I spoke of structure and infrastructure, lets now move a little deeper.
More...

Tags: frameworks, architecture, design, design patterns, methodology