ProxyAttribute… Interesting… Might have to check this out…

http://msdn.microsoft.com/en-us/library/system.runtime.remoting.proxies.proxyattribute.aspx

Advertisements

dynaTrace Ajax

http://ajax.dynatrace.com/pages/download/download.aspx

Tool for very deep analysis of Internet Explorers guts! 🙂

John Resig has a post showing some of the details here

Currency Formatting using Culture Name

I’ve been trying to figure out a way to format monetary values based on the ISO Currency Symbol which is are 3 letter string like: USD, AUD, CRC, EUR; that define a currency.

In .NET the RegionInfo class contains an ISOCurrencySymbol property which returns the Currency Symbol for the given region. Now on my system there are seven regions that have “USD” and I can’t use that to format monetary values.

A RegionInfo is constructed takes a culture string like “ar”, “ar-DZ", “en”, “en-US” etc. and each of these cultures has a specific Currency Symbol. So to format a monetary value we only need the culture string/name.

With the Culture Code we can get all the RegionInfo as well as the benefits of being able to format the currency suitably.

Code Example Available Here

The DoCulture method (badly named) shows how to get relevant RegionInfo like the ISO currency symbol as well as how to format based on the culture.

Posted in Uncategorized. Tags: . 2 Comments »

Inheritence Hierarchy

Dzmitry Huba wrote the following here about Inheritence:

If two or more classes share only common data (no common behavior), then that common data should be placed in a class that will be contained by each sharing class.

If two or more classes have common data and behavior (i.e., methods), then those classes should each inherit from a common base class that captures those data and methods.

If two or more classes share only a common interface (i.e., messages, not methods), then they should inherit from a common base class only if they will be used polymorphically.

… Just something I want to ponder at some point soon.

Repository Pattern

Updated 2009-12-30 – Adjusted  the title to be a general post about the Repository pattern, added links to other posts, forum entries and information, slightly re-organized.

I’ve been looking at the general problem of developing an API and the issues that result, and this is in the context of the repository pattern particularly. Though I don’t think the issues are any different when not using the repository pattern. You still need to be able to load the data you need and avoid issues like: If I Eager load I’ll have way to much data, if I load it when i need it I’ll be opening connections all over the place. With the repository pattern you break the practice of separation of concerns if you inject a reference to any required repositories or services etc. If you actually just provide somewhere on an entity to put it’s sub-entity or a collection and only load it when you need it… well that just doesn’t feel right at all…

Definition of the Repository Pattern

The lazy Loading Approach

The Non Lazy Loading Approach

Use the Repository Pattern

Don’t Use the Repository Pattern

Examples and others

jQuery Plugins List

Controllers in another Assembly in MVC

I was looking for information about putting controllers in a seperate assembly(dll) as a test to see whether I would be able to create some sort of plugin mechanims where the plugin assembly contains the controllers needed for that plugin.

I came across this post in a forum which simply stated says that you need to do this:

  1. Create your web application
  2. Create your class library for your controllers
    1. Reference the System.Web.Extensions.dll
    2. Reference the System.Web.MVC.dll
  3. From your web application, reference the class library

And that is it! You can create your controllers in the class library and everything will just work (Except you won’t be able to right click on an action and click “Add View…” and some of the other nice thing like that!)

It seems that the MVC framework looks in the whole appdomain for any class that implements IController…