What type of Unity 1.0 quick start examples are you looking for?

Developer
May 15, 2008 at 5:54 PM
Edited May 15, 2008 at 6:09 PM

Folks,

If you find a better way to learning Unity by quick start examples; I am in the process of doing additional quick start examples of Unity 1.0.
These examples would demonstrate a particular feature(s) of Unity 1.0, and hopefully will enable you to utilize the Unity framework in your application and design earlier.

In order to exploit the helpfulness of these quick start examples. I would need your input (reply to this thread here) for what kind of quick start examples are you looking for?


Based on what comes out, I will create the Work Item at Issue Tracking and you can follow up the progress. Also some other contributors or developers on here may already have what you need and may construct a sample as well.

Regards,

Alexander

 

 

May 15, 2008 at 6:57 PM
Something based around a web application would be nice

In particular covering
1.  lifetime managers
2.  Some kind of batch registration
3.  Managing large configuration files
4.  Demonstrating where to use the container compared with where not to use the container

Joe






Developer
May 15, 2008 at 9:18 PM
Edited May 15, 2008 at 9:21 PM

Joe,

Here in CET (Central Europe Time) is almost time to go sleep, so I will take a look of these items tomorrow and break them down for proposal of workable items. I already have some profiling statistics for point 4 which would not take a long to make it presentable form. Anyhow till tomorrow... 

 

Regards,
Alexander

Developer
May 16, 2008 at 5:33 PM

Joe,

Can you expand a bit more of your topics below? For example, are you looking for web samples that would use the Unity default lifetime managers and how these would affect web application, or how to create external lifetime managers? Also batch registration and configuration, which scenarios you had on your mind?  

Regards,

Alexander

Developer
May 16, 2008 at 5:49 PM

Joe,

Also what came up to mind is that EntLib configuration block could make sense for large configuration of the Unity.  But again, I need to narrow these options a bit more what you looking for.

Regards,
Alexander

May 16, 2008 at 9:57 PM
Sure

1.  lifetime managers -- in a web application you would probably prefer your instances are created on a per request (or per web request) basis, however there are times when a singleton would fit.   When is the right time to use the singleton vs the per request.  Would putting together a per web request (like Windsor) lifetime manager be out of scope?

2.  batch/bulk registration -- having thought about it, this is probably as easy as looping through the types in an assembly.  However, might be useful as an idea of how to use the container - i.e., are we better off configuring via xml or organizing my assemblies a little better so that our services are grouped together and easy to find via code.

3.  configuration files -- Im not at all familiar with the entlib configuration block (so I guess for me this would be a good place to learn about it).   My concern is that 1000 line xml files will introduce more friction than needed in my process, so whats the recommended way to deal with that. 

4. where to use the container -- my understanding is that in a perfect world IoC.Resolve<T> would be called once and only once per application.  However, its not a perfect world, so when should we be using the container to resolve dependencies?  When is a good time for anything other than your "starting point" to be aware that IoC is even available.

Probably what I have suggested may be more along the lines of best practices and "why" as opposed to a quick start, but I for one would be very thankful for a quick start that answered these questions as opposed to yet another "heres a three page, two component basic blog" example.

Thanks
Joe
alexanderQX wrote:

Joe,

Can you expand a bit more of your topics below? For example, are you looking for web samples that would use the Unity default lifetime managers and how these would affect web application, or how to create external lifetime managers? Also batch registration and configuration, which scenarios you had on your mind?  

Regards,

Alexander




Developer
May 17, 2008 at 3:38 PM
Edited May 17, 2008 at 3:43 PM

Joe, Thanks these are very clear points, and will guidance the effort of these quick samples or pratice notes. I will create work items for these above points, and based on how other members are voting them we tackle them here.

About Enterprise Library possibility, Configuration Application Block doesn’t really exist anymore, and it has been replaced by Enterprise Library IConfigurationSource interface. This inteface enables you to use different repository implementations. For example, you could load your configuration from other files than App.config/web.config or even from an SQL server.

Read more about this topic (which is probably the answere to your points 2 and 3 above) from Tom Hollander blog article “External configuration files in Enterprise Library for .NET Framework 2.0” http://blogs.msdn.com/tomholl/archive/2006/04/02/entlib2externalconfig.aspx 


Regards,
Alexander

 

 

 

Developer
May 17, 2008 at 5:50 PM

Joe,

I created the associated work item, and will start looking them by Monday.

Regards,
Alexander


JoeLowrance wrote:
Sure

1.  lifetime managers -- in a web application you would probably prefer your instances are created on a per request (or per web request) basis, however there are times when a singleton would fit.   When is the right time to use the singleton vs the per request.  Would putting together a per web request (like Windsor) lifetime manager be out of scope?

2.  batch/bulk registration -- having thought about it, this is probably as easy as looping through the types in an assembly.  However, might be useful as an idea of how to use the container - i.e., are we better off configuring via xml or organizing my assemblies a little better so that our services are grouped together and easy to find via code.

3.  configuration files -- Im not at all familiar with the entlib configuration block (so I guess for me this would be a good place to learn about it).   My concern is that 1000 line xml files will introduce more friction than needed in my process, so whats the recommended way to deal with that. 

4. where to use the container -- my understanding is that in a perfect world IoC.Resolve<T> would be called once and only once per application.  However, its not a perfect world, so when should we be using the container to resolve dependencies?  When is a good time for anything other than your "starting point" to be aware that IoC is even available.

Probably what I have suggested may be more along the lines of best practices and "why" as opposed to a quick start, but I for one would be very thankful for a quick start that answered these questions as opposed to yet another "heres a three page, two component basic blog" example.

Thanks
Joe
alexanderQX wrote:

Joe,

Can you expand a bit more of your topics below? For example, are you looking for web samples that would use the Unity default lifetime managers and how these would affect web application, or how to create external lifetime managers? Also batch registration and configuration, which scenarios you had on your mind?  

Regards,

Alexander







May 19, 2008 at 8:47 PM
For what it's worth, I do have implementations some other lifetime managers - per thread, per request, per session, and I think I did an ASP.NET cached one as well. They're written and ready to go. I just haven't had a chance to post them yet. With Entlib 4 out the door, I should be able to get them out there this week.

As such, if you want to use them in quickstarts (once I post them) feel free. Either that or they could make good examples of writing custom lifetime managers.

-Chris

Developer
May 20, 2008 at 9:43 AM
Great, then this topic is resolved by these examples. :-)

Regards,
Alexander
May 21, 2008 at 12:20 PM
Couple of samples dwelling on container extensions creation would be also nice-to-have. Documentation section says only that developer needs to know OB specifics and that's all. Sounds quite abusing I think.
Jun 20, 2008 at 10:49 PM
We are well aware that the extension documentation is missing. It was a question of waiting another month or more to release with the extension docs or ship now and do the extension docs later.