The [XmlIgnore] and [NotMapped] properties are for serialization. If for some reason somebody wants to serialize the entire business object these properties are not included in the serialized output. Generally serializing a business object isn't a good idea, but I found some people using this did it anyway. Generally you would want to serialize the entities.

This class is part of the West Wind Web Toolkit. The class is part of the Westwind.BusinessFramework project/assembly. All the source is available in the Subversion repository or via the download. You can also get this into your project very easily with Nuget:

http://nuget.org/packages/Westwind.BusinessFramework

Unfortunately there isn't much in the way of documentation other than the examples. This is mainly because it's not an official tool but part of my internal library although a number of people use it. I've been meaning to add documentation but since this is not a revenue generator it's been on the backburner for me unfortunately. :-(

+++ Rick ---

>One extra question in regards to your code - why do you have [XMLIgnore] [NotMapped] through the code? I made a quick google search, found an interesting article
>http://weblogs.asp.net/manavi/archive/2010/12/11/entity-association-mapping-with-code-first-part-1-one-to-one-associations.aspx
>
>but want to understand it better and also need some samples of using your class.
>
>Also, is this class a separate project?
>
>>Hi Naomi,
>>
>>Don't take this the wrong way, but there are few things problematic with this code.
>>
>>First it's not a repository pattern at all since the class is mixing the repository with the actual data access layer (DbContext). The whole point of a repository is that it's separate and potentially replaceable which is impossible with the code you have here because the DbContext is directly built into the class.
>>
>>The general idea for a repository - or even a more classic business object type approach - is to have the data access layer a property on the repository/business object rather than a single object that does all this in one place. This allows for better abstraction and isolation and possible replacement of the data access layer.
>>
>>Generally for Entity Framework code you create your model and your DbContext class, and then a separate repository class works with that model either in static methods which create the context and do atomic operations on the context/model, or alternately (which is more familiar to Fox developers) you have a 'business object' class that acts like a repository that's an instance and you fire methods on.
>>
>>Also your code doen't need all those IQueryable properties. DbSet can be directly accessed to get an IQueryable at any time. Anywhere IQueryable is used you can pass a DbSet to. Most likely though anytime you use the DbSet you will automatically apply a .Where() or OrderBy() or .FirstOrDefault() etc. that will automatically cast the result to the appropriate type. Get rid of those properties - they serve absolutely no purpose...
>>
>>
>>Personally I prefer the old school business object type class - which offers more flexibility and reuse as you can easily implement base CRUD operations. If you're interested take a look at the Westwind.BusinessFramework EfCodeFirstBusinessBase< TEntity,TContext > that provide a ton of functionality without any code at all. The class code is available - you can probably get some ideas from that:
>>
>>http://goo.gl/PxtxP
>>
>>Basically it's one class per logical business entity (which doesn't necessarily map a single EF entity)... I've been using this framework in various backend inplementations from LINQ to SQL, original Entity Framework and now with EFCodeFirst for about 5 years and it's been working great. It's pretty small and fairly self-contained (two main classes plus a few support helpers for raw SQL access if necessary and Validation).
>>
>>There are lots of ways to skin this cat of course but for my once FoxPro centric brain the above methodology to data access has served me well for well over 20 years :-)
>>
>>+++ Rick ---
>>
>>>This is MVC application I am working on. I have the Repository class with this code:
>>>
>>>

>>>using System.Data.Entity;
>>>using System.Linq;
>>>using CardNumbers.Objects;
>>>
>>>namespace CardNumbers.Data
>>>{
>>>    public class Repository : DbContext, IRepository
>>>    {
>>>        public DbSet<Client> Clients { get; set; }
>>>        public DbSet<ClientOrder> ClientOrders { get; set; }
>>>        public DbSet<Reorder> Reorders { get; set; }
>>>        public DbSet<Operator> Operators { get; set; }
>>>
>>>        IQueryable<Client> IRepository.Clients
>>>        {
>>>            get { return Clients; }
>>>        }
>>>
>>>        IQueryable<ClientOrder> IRepository.ClientOrders
>>>        {
>>>            get { return ClientOrders; }
>>>        }
>>>
>>>        IQueryable<Operator> IRepository.Operators
>>>        {
>>>            get { return Operators; }
>>>        }
>>>
>>>        IQueryable<Reorder> IRepository.Reorders
>>>        {
>>>            get { return Reorders; }
>>>        }
>>>
>>>        public void Commit()
>>>        {
>>>            this.SaveChanges();
>>>        }
>>>
>>>        public void AddClient(Client client, bool autoCommit = true)
>>>        {
>>>            Clients.Add(client)   ;
>>>            if (autoCommit) Commit();
>>>        }
>>>
>>>        public void DeleteClient(Client client, bool autoCommit = true)
>>>        {
>>>            Clients.Remove(client);
>>>            if (autoCommit) Commit();
>>>        }
>>>
>>>        public void DeleteClient(int clientId, bool autoCommit = true)
>>>        {
>>>            var ReordersQuery = from reord in this.Reorders
>>>                                where reord.ClientId == clientId
>>>                                select reord;
>>>
>>>            if (ReordersQuery.Any())
>>>               // throw "Client " + clientId.ToString() + " can not be deleted because it has related rows in the ReOrders table!";
>>>
>>>        }
>>>
>>>
>>>        public void AddOperator(Operator oOperator, bool autoCommit = true)
>>>        {
>>>            Operators.Add(oOperator);
>>>            if (autoCommit) Commit();
>>>        }
>>>
>>>        public void DeleteOperator(Operator oOperator, bool autoCommit = true)
>>>        {
>>>            Operators.Remove(oOperator);
>>>            if (autoCommit) Commit();
>>>        }
>>>
>>>        public void AddOrder(ClientOrder clientorder, bool autoCommit = true)
>>>        {
>>>            ClientOrders.Add(clientorder);
>>>            if (autoCommit) Commit();
>>>        }
>>>    }
>>>}
>>>

>>>
>>>Since I am going to call DeleteClient method, I am thinking I may need less generic variation and manually test dependencies myself. So, I started to write a version that will delete based on id.
>>>
>>>Perhaps I don't need this method?
>>>
>>>I started to write it based on this logic I found in MSDN after I googled on 'LINQ delete' http://msdn.microsoft.com/en-us/library/bb386925.aspx
>>>
>>>
>>>
>>>
>>>>Let's backup a bit.
>>>>
>>>>Is this a web app or desktop? Where is the context defined?
>>>>
>>>>>Hi everybody,
>>>>>
>>>>>I am writing a method to delete a cient in my Repository class. Here is what I've started from:
>>>>>
>>>>>

>>>>>public void DeleteClient(int clientId, bool autoCommit = true)
>>>>>        {
>>>>>            var ReordersQuery = from reord in this.Reorders
>>>>>                                where reord.ClientId == clientId
>>>>>                                select reord;
>>>>>
>>>>>            if (ReordersQuery.Any())
>>>>>                //throw "Client " + clientId.ToString() + " can not be deleted because it has related rows in the ReOrders table!";
>>>>>
>>>>>        }

>>>>>
>>>>>I read help on throw as I need to throw a new exception. My question is - what kind of exception it should be?
>>>>>
>>>>>Thanks in advance.