ignorance

<h1>A little Persistence Ignorance framework that features those Unit of Work, Repository, and Inversion of Control patterns you keep hearing so much about.</h1> Only, now you're not pecking them out and maintaining them in your application code, because Ignorance already did that. So, in much the same way that your business logic will be carefree and clueless about how your data is persisted, you get to skip down the hallway and be all, "la la, business code, business code", and not give two squirts about implementing another IRepository. <h2>You Know I'm Not Switching To Another ORM Tomorrow, Right?</h2> Yep. Because that's exactly what I said. But let's say you have this amazing web app, and now you want to build out a occasionally-connected native client for it. Well, now your logic needs to work with local storage. And that local storage<a href="http://msdn.microsoft.com/en-us/library/hh202860(v=VS.92).aspx" target="_blank"> doesn't do Entity Framework</a>. If your domain and client logic is peppered with Entity Framework-specific hooks, you can't just reuse that DLL. That DLL that already contains your carefully curated and tested and trusted domain logic. That DLL that is the heart and identity of your application. Persistence Ignorance makes that logic portable, self-contained, instantly reusable. What's more, it's dead simple to test what's unique and important about your app. Mock up your database, don't muck up your database. <h2>Just Show Me The Code</h2> Okay. So your client code will be all: <pre style="background: white">// hey kids, let's add a new contact  using (var work = Ignorance.Create.Work()) {     // create a service object,       // which houses any logic around data types      var contacts = new ContactService(work);     // instantiate & init a new contact object     var c = contacts.Create();     c.FirstName = "Merlin";     c.LastName = "Mann";     c.Title = "Hi. Can I Axe You A Question?";     // add it to your list of contacts (repository)     contacts.Add(c);     // validate and commit changes     work.Save(); }       </pre> Then, your logic/business/domain code is all: <pre style="background: white">using System; using System.Collections.Generic; using Ignorance; using Ignorance.Domain; using YourApplicationHere.Data; namespace YourApplicationHere.Domain {     public class ContactService : Service<Contact>     {         public ContactService(IWork work) : base(work) { }         protected override void OnCreated(Contact entity)         {             entity.FirstName = "New";             entity.LastName = "Guy";             entity.Suffix = "Esq.";         }         protected override void OnSaving(Contact entity)         {             if (!entity.EmailAddress.Contains("@"))                 throw new ApplicationException("That's not an email address.");         }         protected override void OnDeleting(Contact entity)         {             if (entity.LastName == "Fazzaro")                 throw new ApplicationException("Don't delete me or my relatives!");         }         public IEnumerable<Contact> GetContactsWithSuffixesBecauseTheyAreAwesome()         {             var repo = GetStore();             return repo.Some(p => p.Suffix != null);         }         public void JustGoAheadAndMakeSureEveryoneHasSuffixesNow()         {             var repo = GetStore();             var unsuffixedPeeps = repo.Some(p => p.Suffix == null);                         foreach (var peep in unsuffixedPeeps)             {                 peep.Suffix = "Esq.";             }         }     } } </pre>

And that's more or less all you're left holding the bag for. I know, right?

That Contact object (and all of its brother and sister data objects) is just

Ignorance

Install / Use

README