One of the common methods to build a Business Component on top of your (EF) DAL is creating a facade to it using the Repository-Pattern. That is, simply define an interface:

public interface IRepository<T>
    {
        T GetById(int id);
        IEnumerable<T> GetAll();
        IQueryable<T> Query(Expression<Func<T, bool>> filter);

    }

and then implementing it:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using AdventureWorksDAL;
namespace AdventureWorksBC
{

    public class ProductRepos : IRepository<Product>, IDisposable
    {
        private AdventureWorksEntities _context;

        public ProductRepos()
        {
            _context = new AdventureWorksEntities();
            var types = AdventureWorksEntities.GetKnownProxyTypes();
        }

        #region IRepository<Product> Members

        public Product GetById(int id)
        {
            return _context.Product.Where(p => p.ProductID == id).FirstOrDefault();

        }

        public IEnumerable<Product> GetAll()
        {
            return _context.Product;
        }

        public IQueryable<Product> Query(System.Linq.Expressions.Expression<Func<Product, bool>> filter)
        {

            return _context.Product.Where(filter);
        }

        #endregion

        #region IDisposable Members

        public void Dispose()
        {
            if (_context != null)
            {
                _context.Dispose();
            }
            GC.SuppressFinalize(this);
        }
        #endregion
    }
}

Ever since I’m lazy…. I want to take this to a higher abstract level. With the preceding solution, you always have to implement the Interface for every object in the datacontext. Of course you want to have BusinessComponents where you can leave specific rules, but those GetAll, GetById – methods are pretty common. Therefore we’ll have to write a base-class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Objects.DataClasses;
using System.Data.Metadata.Edm;
using AdventureWorksDAL;
using System.Data.Objects;
using System.Data;
using System.Linq.Expressions;

namespace AdventureWorksBC
{
    public class RepositoryBase<T> : IDisposable where T : EntityObject, new()
    {
        //private IQueryable<T> _entity;

        private AdventureWorksEntities _context;
        private ObjectSet<T> _query;

        public RepositoryBase()
        {
            _context = new AdventureWorksEntities();
            _query = _context.CreateObjectSet<T>();
        }

        public T GetById(int id)
        {

            foreach (T entity in _query)
            {
                if ((int)entity.EntityKey.EntityKeyValues[0].Value == id)
                {
                    return entity;
                }

            }
            return null;
        }

        public IEnumerable<T> GetAll()
        {
            return _query;

        }

        public IQueryable<T> Query(Expression<Func<T, bool>> filter)
        {
            return _query.Where(filter);
        }

        #region IDisposable Members

        public void Dispose()
        {
            if (_context != null)
            {
                _context.Dispose();
            }
            GC.SuppressFinalize(this);
        }
        #endregion
    }
}

Well that’s our baseclass. Let me short explain;

public class RepositoryBase<T> : IDisposable where T : EntityObject, new()

As you see we’ve replaced the specific object (like “Product” or “Customer”) with a generic “T”. After this you see the constraint: “it must be of type EntityObject, and have a parameterless constructor”.
Then in the constructor we’re going to initialize our fields_: context and _query. _query now returns an ObjectSet of type T (also it grabs all of those entities from the context).

The methods “GetAll” and “Query” are somehow self explainable I think, so leave them for now.
What really is kind of tricky is “GetById(int id). Honestly I have not figured out yet a better way to do this, but the end justifies the means…

Well now look at a demo app to show what you could do with this base-class:

First define a few childclasses:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using AdventureWorksDAL;

namespace AdventureWorksBC
{
    public class ContactRepository : RepositoryBase<Contact>
    {
        public ContactRepository()
        {

        }
    }
    public class ProductRepository : RepositoryBase<Product>
    {
        public ProductRepository()
        {

        }
    }

}

Now call our entities through our new BusinessComponent:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Objects;
using AdventureWorksDAL;
using AdventureWorksBC;
using System.Data.Metadata.Edm;

namespace DemoEFBusinessComponent
{
    class Program
    {
        static void Main(string[] args)
        {

            var productRepos = new ProductRepository();
            Product product = productRepos.GetById(319);
            Console.WriteLine(string.Format("productId: {0}",product.ProductID));
            Console.WriteLine(string.Format("Name: {0}", product.Name));
            Console.WriteLine(string.Format("Model: {0}", product.ProductNumber));
            productRepos.Dispose();
            Console.Read();

            var contactRepos = new ContactRepository();
            var contacts = contactRepos.GetAll();

            foreach (Contact contact in contacts)
            {
                Console.WriteLine(string.Format("contactId: {0}", contact.ContactID));
                Console.WriteLine(string.Format("LastName: {0}", contact.LastName));
                Console.WriteLine(string.Format("Email: {0}", contact.EmailAddress));
                Console.WriteLine("");
            }
            contactRepos.Dispose();
            Console.Read();

            var productCategoryRepos = new RepositoryBase<ProductCategory>();
            var specificCategory = productCategoryRepos.Query(pc => pc.Name.StartsWith("co"));
            foreach (ProductCategory category in specificCategory)
            {
                Console.WriteLine("productCategoryId: {0}", category.ProductCategoryID);
                Console.WriteLine("productCategoryName: {0}", category.Name);
            }
            productCategoryRepos.Dispose();
            Console.Read();

        }
    }
}

This turns out rather cool, since you don’t have to define childclasses like “public class ProductRepository : RepositoryBase” for instance. Obvious, but let me mention: It’s really up to business whether you need them.

If you try this at home please forgive me for the endless “adventureworks” contacts list!

Thank you:Gil Fink

Somehow the wcf data service will look like:

using System.Collections.Generic;
using System.Data.Services;
using System.Linq;
using System.ServiceModel.Web;
using System.Web;
using System.Linq.Expressions;
using System.Data.Services.Common;

namespace TestAdventureWorksDataServices
{
    public class AdventureService : DataService<AdventureWorksEntities>
    {
        // This method is called only once to initialize service-wide policies.
        public static void InitializeService(DataServiceConfiguration config)
        {
            // TODO: set rules to indicate which entity sets and service operations are visible, updatable, etc.
            // Examples:
            config.SetEntitySetAccessRule("*", EntitySetRights.All);
            // config.SetServiceOperationAccessRule("MyServiceOperation", ServiceOperationRights.All);
            config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
            config.UseVerboseErrors = false;
        }

        protected override void HandleException(HandleExceptionArgs args)
        {
            throw new DataServiceException(args.Exception.InnerException.Message, args.Exception);
        }

    }
}

Once we’ve setup our service, it’s time for a client that makes some calls to it. First add a new project to the solution (ConsoleApplication for now) and make a ServiceReference to the service.
In this example we want to add 3 new products and persist them in the DB producttable. For the last part we don’t have to worry, since the Entity Framework will handle this all.
Take a look at the client:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Services.Client;

namespace Client
{
    using Client.AdventureWorksServiceReference;

    class Program
    {
        private static AdventureWorksEntities _context = null;

        static void Main(string[] args)
        {
            _context = new AdventureWorksEntities(new Uri("http://ipv4.fiddler:51824/AdventureService.svc"));

            var product1 = Product.CreateProduct(0, "My Test Product 1", "1234", true, true, 1, 1, 100, 200, 3,
                                                DateTime.Now, new Guid("E29C16AE-908A-4F53-8E19-DC2CFDDF08A0"), DateTime.Now);

            var product2 = Product.CreateProduct(0, "My Test Product 2", "5678", true, true, 1, 1, 200, 300, 3,
                                     DateTime.Now, new Guid("1B9689D6-CCFF-40C3-AA0F-1AC3C5951738"), DateTime.Now);

            var product3 = Product.CreateProduct(0, "My Test Product 3", "9876", true, true, 1, 1, 300, 400, 3,
                         DateTime.Now, new Guid("{0B677FB4-890E-4FAF-AD6A-7477D5703E6E}"), DateTime.Now);

            var collection = new DataServiceCollection<Product>(_context);
            collection.Add(product1);
            collection.Add(product2);
            collection.Add(product3);
            _context.SaveChanges();

            Console.Read();

            //remove products to omit unique constraint next time running this app:
            collection.Remove(product1);
            collection.Remove(product2);
            collection.Remove(product3);
            _context.SaveChanges();

            Console.WriteLine("Deleted. Sorry, changed my mind!");
            Console.Read();

        }
    }
}

A short walkthrough of what is happening here.
First, take note of instead of setting up the context by calling “http://localhost:51824/AdventureService.svc” we include “http://ipv4.fiddler:51824/AdventureService.svc”. This is done so that later on we can monitor our calls in Fiddler.
When the application fires, a context of our service is setup, which will track all changes. In the end, if we agree with those changes we can call “context.SaveChanges()”;
By calling SaveChanges() requests are finally made to store the products. Let’s take a look in Fiddler:

As you see, there are 3 requests made to the service. Note!: by calling SaveChanges() only once.
Now let’s do it again, but change some code:
change following line:

_context.SaveChanges();

into:

_context.SaveChanges(SaveChangesOptions.Batch);

check this out in fiddler and you’ll notify the call is only made once:

Authentication
Fact: You could use asp.net form based authentication, windows authentication etc.. This for me wasn’t an option, because of the service’s “open” character. One would bother customers having a complex implementation time; assembling cookies, firing exotic client tools or spent hours on learning the-microsoft-way when they’re not used to it (which isn’t a bad thing of course, but let’s respect our fellow developers ) Although, I wanted to leave the MembershipProvider -’pattern’ in, cause this comes in very handy.

I descided to go for a SSL/Basic Authentication solution, which is absolute secure!! (There are other discussions on this, which I leave out for now). Let’s talk about Basic Authentication for one minute:

On an Http-Request, Before transmission, the user name is appended with a colon and concatenated with the password. The resulting string is encoded with the Base64 algorithm. For example, given the user name Aladdin and password open sesame, the string Aladdin:open sesame is Base64 encoded, resulting in QWxhZGRpbjpvcGVuIHNlc2FtZQ==. The Base64-encoded string is transmitted and decoded by the receiver, resulting in the colon-separated user name and password string.

First thing we have to do is design some kind of a mechanism to handle requests containing these credentials and authenticate our user through a custom MembershipProvider.
Let’s start by creating a new class implementing the IHttpModule:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Web.Security;
using System.Security.Principal;
using NL.ADA.TNT.CustomService.Modules;
using Ada.Cdf.Logging;

namespace NL.ADA.TNT.CustomService.Modules
{
    public class ODataServiceModule : IHttpModule
    {

        private CustomMembershipProvider membershipProvider;
        private Logger _logger;

        public ODataServiceModule()
        {
            _logger = new Logger();
        }

        #region IHttpModule Members

        public void Dispose()
        {
            _logger.Log(LogEvent.EnterEvent);
            membershipProvider = null;
            _logger.Log(LogEvent.LeaveEvent);
        }

        public void Init(HttpApplication
{
            membershipProvider = (CustomMembershipProvider)Membership.Provider;
            context.AuthenticateRequest += new EventHandler(context_AuthenticateRequest);
            context.AuthorizeRequest += new EventHandler(context_AuthorizeRequest);
            context.BeginRequest += new EventHandler(context_BeginRequest);
        }

        void context_BeginRequest(object sender, EventArgs e)
        {
                   HttpApplication context = sender as HttpApplication;
            if (context.User == null)
            {
                if (!TryAuthenticate(context))
                {
                    SendAuthHeader(context);
                    return;
                }

            }

        }

        void context_AuthorizeRequest(object sender, EventArgs e)
        {
		//insert custom code
        }

        void context_AuthenticateRequest(object sender, EventArgs e)
        {

            //TODO: rules?
            HttpApplication context = sender as HttpApplication;
            TryAuthenticate(context);

        }

        #endregion

        private void SendAuthHeader(HttpApplication context)
        {
            context.Response.Clear();
            context.Response.StatusCode = 401;
            context.Response.StatusDescription = "Unauthorized";
            context.Response.AddHeader("WWW-Authenticate", "Basic realm=\"Secure Area\"");
            context.Response.Write("401 please authenticate");
            context.Response.End();

        }

        private bool TryAuthenticate(HttpApplication context)
        {

            string authHeader = context.Request.Headers["Authorization"];

            if (!string.IsNullOrEmpty(authHeader))
            {
                if (authHeader.StartsWith("basic ", StringComparison.InvariantCultureIgnoreCase))
                {

                    string userNameAndPassword = Encoding.Default.GetString(
                        Convert.FromBase64String(authHeader.Substring(6)));
                    string[] parts = userNameAndPassword.Split(':');

                    if (membershipProvider.ValidateUser(parts[0], parts[1]))
                    {
                        var userIdentity = new GenericIdentity(parts[0].Trim(), "Basic");
                        context.Context.User = new CustomServicePrincipal(userIdentity);

                        return true;
                    }
               }
            }

            return false;
        }
    }
}

As you can see, we create a new Principal in this line:

context.Context.User = new CustomServicePrincipal(userIdentity);

I’ll come back to this in a minute. First you’ll have to notice this is a custom module that enables you to handle basic-authentication in IIS (7.5).
Next we’ve to register this as a custom module in IIS…

….and disable all authentication-options, except anonymous:

For now our module is set and intercepts each request doing our custom thing.

Authorization

As I mentioned earlier, for the actual authorization purpose we create a custom principal. that is a new Class that inherits GenericPrincipal. By doing this we’re able to “write” our user to the HttpContext and can call it’s UserPermissionSet property anytime:

   public class CustomServicePrincipal : GenericPrincipal
    {
        private IIdentity _identity;
        private MyEntities _context;

        public CustomServicePrincipal(IIdentity identity)
            : base(identity, new string[] { })
        {

            _context = new MyEntities();
            _identity = identity;
            UserPermissionSet = GetUserPermissionSet();
        }

        public Permission UserPermissionSet { get; set; }
        private Permission GetUserPermissionSet()
        {
            try
            {
                var query = from up in _context.UserPermissions
                            where up.User.UserName == this.Identity.Name
                            select up.Permission;

                Permission flags = 0;
                foreach (var userPermission in query)
                {
                    flags |= (Permission)userPermission.ID;
                }
                return flags;

            }
            catch (Exception ex)
            {

                throw new Exception(string.Format("could not get permissionset for current user{0}", this.Identity.Name), ex.InnerException);
            }

        }

     }

Please note: the permissionset is received from the database (thru entity-framework 4.0). If you want to authorize methods, properties and so on, the thing that worked for me is to handle those permissions as bitwise “flags” so that later on you can compare very easily throughout all the application. To make this clear, here’s an example:

   [Flags]
    public enum Permission
    {
        userMayReadBedtimeStories = 1,
        userMayReadHorrorStories = 2,
        userMayReadHumoristicStories = 4,
        userMayReadNewsStories = 8,
        userMayReadOtherKindoStories = 16,
        userMayPostStory = 32

    }

At the persistance-level I stored these permissions in a “permission”-table which relates to table “User”. Username and Password are stored here also. Permissions for each user we’ll get from the “UserPermission”-crosstable.

Now we’re ready to demand some of these permissions on a method:

        [ChangeInterceptor("Stories")]
        public void OnChangeStory(Story story, UpdateOperations updateOperations)
        {
                      AuthDemand(Permission.userMayPostStory);
//add a story
.
.
.
}
        private void AuthDemand(Permission demandPermissions)
        {
            var userPermissionSet = (HttpContext.Current.User as CustomServicePrincipal).UserPermissionSet;
            if ((userPermissionSet & demandPermissions) != (demandPermissions))
            {
                throw new Exception("no permission");//put whatever you want to throw here
            }
        }

thank you also:
Bjorns Blog

Wondering how to bind most directly to the twitter API I came accross the following solution; Instead of binding to classes which are generated from the Xml spit out by the Api, I thought of the XmlDataProvider is a more proper way of doing…
First here’s the xaml:

<Window x:Class="WpfTwitter.TwitterView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Twitter View" Height="300" Width="300">
    <Window.Resources>
        <XmlDataProvider x:Key="DataProvider"/>
    </Window.Resources>
    <Grid>
        <ListBox Width="300" Height="500" ItemsSource="{Binding Source={StaticResource DataProvider}, XPath='users/user'}">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Background="Aqua">
                        <Image Source="{Binding XPath='profile_image_url'}" Width="50" Height="50"/>
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>

    </Grid>
</Window>

For a more loosely coupled design I’ve chosen the PRISM way: MVP -> model view presenter.:
For this of course you need all 3:
Model: TwitterPresentationModel
View: TwitterView
Presenter: TwitterPresenter

Now the TwitterView implements the ITwitterview, which holds a reference to the model:

public interface ITwitterView
{
TwitterPresentationModel Model { get; set; }
}

The model will hold the xmldocument returned from twitter:

namespace WpfTwitter
{
public class TwitterPresentationModel:XmlDocument
{
public TwitterPresentationModel()
{

}
}
}

Notice that it is just inherited from XmlDocument. That will do for now.

Then in the presenter we control both view and model:

public class TwitterPresenter
{
private ITwitterView view;
private Yedda.Twitter twitter;
public TwitterPresenter(ITwitterView view)
{
twitter = new Yedda.Twitter();
var twitterPresentationModel = new TwitterPresentationModel();
twitterPresentationModel.LoadXml(twitter.GetFriends(“user”, “password”, Yedda.Twitter.OutputFormatType.XML));
view.Model = twitterPresentationModel;
}
}

Here I used the Yedda twitter Library Really usefull. All methods from the twitter api are implemented!

In the TwitterView.cs we’ll start to bind some things:

public partial class TwitterView : Window, ITwitterView
{
public TwitterView()
{
InitializeComponent();
var presenter = new TwitterPresenter(this);
}

public TwitterPresentationModel Model
{
get
{
return (this.Resources["DataProvider"] as XmlDataProvider).Document as TwitterPresentationModel;
}
set
{
(this.Resources["DataProvider"] as XmlDataProvider).Document = value;
}
}
}

As you can see, we hook the XmlDataProvider to the Model. Thus, Provider becomes Model and Provider becomes Model.
The only thing that’s left is binding the list to the model. As you can see in the xaml, this is done by binding to the XmlDataProvider and setting the datatemplate-binding to the user node
of the Xml. All can be done with XPath, which a vast bunch o developers still might love:

        <ListBox Width="300" Height="500" ItemsSource="{Binding Source={StaticResource DataProvider}, XPath='users/user'}">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Background="Aqua">
                        <Image Source="{Binding XPath='profile_image_url'}" Width="50" Height="50"/>
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>

Great! Try it, use it, love it…

Frans.

“An error occurred while trying to make a request to URI ‘http://localhost:1528/MyService.svc’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a …….. etc. etc. etc.”

Just paste the following into an XML (name it: ‘clientaccesspolicy.xml’ ) located in the root of your service application:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
<policy>
      <allow-from http-request-headers="*">
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

In fact you can do more with policies on crossdomain-issues. Please read:

msdn on this topic
Sajai's blog

A simple solution for this is simply setting the Width and Height property of the ItemContainerStyle:

                <ListBox.ItemContainerStyle>
                    <Style TargetType=”ListBoxItem”>
                        <Setter Property=”Width” Value=”0″/>
                        <Setter Property=”Height” Value=”0″/>
                    </Style>
                </ListBox.ItemContainerStyle>

Although it might be not the most proper solution, it does prevent you from using and customizing the ItemsControl. One of my concerns was to keep all of the selection-functionality from the ListBox Control.

CAL and Silverlight go together under the name of Prism, which you can find on codeplex.

http://www.codeplex.com/CompositeWPF 

The CAL guidance lets us build a (enterprise-level) client application composed of pieces, that maybe have been designed and developed in different teams. Those pieces will come together and build modules. This module-approach will lead to the composite-application, nicely build up of loosely-coupled parts.

Please read the msdn documentation here

Prism is cooool, because now all those great things we can do in Silverlight too!

Next post I want to share a way to show a usercontrol (by demand) by using  a (Global) Command.

• The server software announced as 64 bit only
• Silverlight Media web parts
• Backup/Restore/Rollback and Snapshot backups with virtual load balancing
• Claims-based authentication
• Possible inclusion of InfoPath style web-based editor – since Office 14 is allowing for some applications to be web-based with limited functionality.
• SQL tables-like behaviour for SharePoint lists    
• PowerShell
• Master Data Management (MDM)
• FAST search (Enterprise Search revamp)
• AJAX based interface
• .NET 4 based
• An STSADM GUI
• Groove and SharePoint will now be fully integrated
• ODF and PDF support
• Content Management Interoperability Services support
• SharePoint 2009’s default web interface will be using the Ribbon interface
• Super-Lists SQL tables-like behaviour for SharePoint lists

Let’s throw some other speculations & interpretations:

1. CKS (Community Kit 4 SharePoint) will be integrated and more: SharePoint will have some facebook looks
2. Podcasting Kit for SharePoint
3. Interactive Media Manager ..?
4. Full blown Internet, Web 2.0 features.
5. A More friendly development environment
6. Workflow. Excessively
7. Since Groove will be integrated I guess you’ll have to buy modules for it.
8. Ghosting/unghosting issues solved.

From a developers perspective I think the new WSS will make our job a lot easier. More templates will be available in VS 2010.  Despite of all Blueprints ‘Silverlight’ now will be fully integrated. The Geneva platform will definitely make its entrance, although some sources mention it to be planned for an SP. For now the baby has to be born. Follow the star… 

Tx to Jaap Steinvoorte for accurate research!