I know what Reflection is but why would I need to use it in a typical line-of-business Winforms app?
One common scenario is to reflect through assemblies to find, load and use plugins for your application.
We also use reflection extensively in the Factory Pattern. Object creation methods can be marked with attributes with are found with reflection and then created by our factory.
In fact, any use of attributes uses reflection. If you create your own attributes, you will use reflection to find them on your code.
We also use reflection to generate code. We have a client/server application that uses .NET remoting. We mark the calls into our server with our own attributes and then use reflection to find them and generate all of our communications code, an assembly for the server and one for the client. It saves all of the rote work of manually adding in the same logging, timing and remoting code everywhere.
You can build user interfaces dynamically based on your DTO's if you happen to use them.
That's kind of loaded question, but some reasons come to mind:
Testing private methods in unit tests.
Using it to sort dynamically with linq when having only a property name available.
Fill an object's property on the fly. Possibly because you are matching the property to a datarow column name or maybe and xml element. (Might be an outdated use)
Creating a class on the fly.
Reflection can help you write more maintanable code and reduce the amount of code for some specific task.
I.e. you could write a simple shell either by using a lot of if statements to match a command, or use reflection to generate a dictionary containing delegates to methods marked with a specific custom attribute to expose it to the user. With the reflection approach, such method only has to be added in a single place and reflection takes care of the rest.
Another common use for reflection is serialization. .Net uses reflection to find type information when serializing objects. A line of business app might want to provide a custom data import/export feature, and serialization via reflection is one way to accomplish that.
I've defined an a DisplayName attribute for my Enum's so you end with:
enum { [DisplayName("Opened") open, [DisplayName("Request for Quote") RFQ
}
Now I can using reflection to pull out the right label. This is handy for data driven applications. You can also put a resource key in there so you can localize it.
I'll use reflection if I want to process somethign based on it's type. So if Im passed Type A go left otherwise go right.
It makes the Factory pattern real easy to expand because you can put information in a config file or a database (and the Factory itself becomes code you never have to touch).
assuming by "line of business app" you mean "a simple CRUD app", then you've defined the scope narrowly enough that you probably do not need reflection to make it work - or even to make it better
reflection makes the language "closed" in the sense that operators in the language can be used to investigate operators in the language; contrast this with the C language, which has no reflection. Want to call a function by name in C? Can't do it, no reflection.
Does the typical C application need to do this? No, or rarely.
Similarly per your question "Why would I use Reflection in a business app?" the answer is that you probably wouldn't, while others may have clever uses for it, but in fact for basic CRUD applications it is not "necessary".
that doesn't mean that you shouldn't understand it; knowing what it is and what it can do can mean the difference between writing a ton of brittle code or a little elegant reflective code, in the event that you ever encounter something more difficult or complex than a 'line of business app' ;-)
Here are just some of the many samples:
- Auto-discover and load components and services within the .NET Inversion of Control Container that we use with .NET reflection
- Enforce design constraints over the code (i.e. "All classes in the Model namespace must be immutable and serilizable") with Cecil-based reflection (sample)
- Add sanity and validation checks to the code to make it more stable with helpers implemented with the IL-based reflection (sample).
- Bind UI controls and error providers to the business objects and business rules with the .NET reflection based on Linq expressions (sample).
Likely uses:
- creating LINQ expressions by hand
- serialization, either inbuilt or bespoke
- data-binding
- data import/export, for example via
HyperDescriptor
- dynamic code generation (
Reflection.Emit
)
If you want to implement the Factory pattern and avoid having to recompile a code everytime you add a new component in the factory, Reflection may be the only option.
We use reflection to be able to map the controls from the UI layer directly to the properties of the business object in the datalayer. This lets you have a 'generic' function on a baseForm someplace that 'auto populates' the BO with the UI data and vice-versa, without having to write code for each and every control and property on the form and object.