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