I like to code and lift weights. I am a full-time Software Engineer for the movie business as well as a freelance coder, and part-time landlord. Received my BS in Computer Science, MBA, MS in Computer Science, and MS in Software Engineering. I spent a few years in the military then working as a contractor overseas which eventually brought me back to the states.

IQueryableSearch

Search all/any properties of an IQueryable with one single search.

The 'quick search' is a great tool. Google has shown us that searching with one single, universal search field is the way that people prefer to search. Anyone who has worked with Linq for any amount of time knows this is possible, but it requires a lot of hard-coding and a long jumble of 'where' statements. This class will allow you to run a universal 'google-like' search on any IQueryable.
More Information

var results = cars.Search(new object[] {"chevy", 2007});
// will search cars for the string "chevy"
// and the int 2007 across all fields

LinqToSql

Universal Get Extensions for your DataContexts, Find the Primary Key of any table, and more

Naspinski.Utilities.GetPrimaryKey<table>();
// will return the PropertyInfo of the Primary Key(s) of 'table'
someDataContext.Get<Car>(someKey);
// is the same as writing:
someDataContext.Cars.FirstOrDefault(x => x.id == someKey);
// regardless of what Type someKey is or what the
// PropertyInfo.Name of the Primary Key is; never write
// a Get accessor again!

FileStreamSave

Simple extension to save a FileStream to disk, option to avoid overwriting will automatically update the filename to avoid overwriting:

someFileStream.Save(@"C:\file.txt")
// will save the file to the given path
// 'file[1].txt' if the file is already there
// the file name will be returned
someFileStream.Save(@"C:\file.txt", false);
// will save the file to the given path,
// overwriting if the file already exists

produce random string simply in .net, without special characters if need be

It is very simple to get random string since the introduction of Membership.GeneratePassword() - so this really just a way to utilize that and pull out special characters if that is what you are looking for.

Now I want to add some methods and validation to the class, but I do not want to edit the class directly. What I need to do is make a partial class and add the things in there. This accomplished two things: 1. separates logic from structure and 2. separates the files so another auto-generation or update will not lose the work you do. This is very simple to do, here is an example:

// be SURE that it is in the same namespace
namespace My.NameSpace
{
//System.ComponentModel.DataAnnotations
[MetadataType(typeof(VWidget))]
public partial class Widget
{
// I want to add another property
public string FullName
{ get { return Name + Id; } }
}
// this is the validation segment
// this is the same as the class name above
public class VWidget
{
[Display(Name = "Widget Name")]
[Required]
[StringLength(50)]
public string Name { get; set; }
}
}

Now this was very simple, but it shows how to add this in. First of all, there is a new property to Widget called 'FullName' which will combine the 'Name' and 'Id' properties. Not really all that useful, but you can see how it is used.

The next part is really cool, you can put all of your validation in the 'VWidget' class (name doesn't really matter here). Here you can see that 'Name' is now required, has a max length of 50 characters, and a label will display "Widget Name" instead of the default property name. This way, if you are using this library with MVC, you can do something this simple:

The first thing in the code is simple declaration of an EntityContext - this is implemented directly, but could (and usually should) be implemented differently for dependency injection, but you get the idea. Here is where I also like to include stuff that is often used and could be vital (and centralized) for an application like an output type for web services (JSON, XML, etc.).

Next the OnActionExecuting is over-ridden and the Context is initialized. Here is where you can initialize the properties you set above.

The next method, the HttpPost Index method is just an example of how often times you can consolidate a commonly used method. For this example, it was from an application that had searches on all index pages. Instead of repeating this code in every controller, you can just put it here.

The final method has become very useful. A use I often find, is when taking in a large model after an Asp.Net MVC POST event, I can attach the model to the Db generically without any extra work

This method is a bit confusing, but it is simply attaching the new model to the Db without a Db lookup. In my tables, I generally have a field 'Id' that houses the Primary Key of every table, whether it is an Int or Guid. This way, I can simply pass in whatever object I am currently working with, and by using the pluralize method, and reflection, the method can figure out which table to attach the model to - eliminating the need for me to do extra coding. Alternatively, if I want to change the Key from 'Id', I can pass that in as well.

Sometimes you need to pluralize names like when you are working with Entity Framework or countless other sitautaions

When you auto-generate from tables in Entity Framework, it will make the table names plural, and the objects singular. Often times, when you are trying to use more generic functions like creating EntityKey objects for attaching to an unknown table, you will need to pluralize a class name, so for this, I came up with a couple static methods to simply return a plural version of an Object's name or a string itself:

Let's face it, you never know what exactly is going to end up with your next application. Has an application ever ended up exactly where it was planned in the beginning? I would say never.

There is an insane amount of writing on the debate of int vs guid, both have their pros and cons, both have storage, index and coding implications and we know (or can find) almost all of them with a simple search. Yet there is no consensus on which is the best, I am not here to add to that discussion.

Therefore I propose using BOTH - hear me out.

I propose that the best solution is to provide ONE of the two as your primary key, I prefer Guid as the PK, as it can be referenced more universally (think recycle bin, etc.), but it does have the added indexing cost of being larger; then simply add the auto-incrementing integer as an additional field. Whichever one you choose as your alternative (integer in my case) is simply as a just-in-case means of accessing your data - also indexed. This provides you the best of both worlds, without too much sacrifice. For example, you get the ubiquity of being able to generate a Guid anywhere (without a DB trip), but also have the ability to access your data by a clean 4-bit integer. If for some reason, the code is accessed by software that relies on integers, you are not stuck without one, and vice-versa.

Yes, this will obviously cause more data to be stored for every entry in a table (I am talking about main tables here, not necessarily lookup tables, etc.). This will cause extra index storage as well, but in the long run, I feel it provides enough advantage and future-proofing to justify the sacrifice. Now tell me how wrong I am...