views:

85

answers:

3
+6  Q: 

defining interface

Hi all,

I have a datamodel used by multiple application that I now needs to be used by other developers outside the team. The model should only be made partialy available to the developers.

I wonder how I best approach this: my current approach is to create a new project that just copies the orginal model and only include the requested properties.

for example

namespace Model
{
    public class Car
    {
        private double m_speed;
        private FuelType m_fuelType;

        public double Speed
        {
            get { return m_speed; }
            set { m_speed = value; }
        }       


        public FuelType FuelType
        {
            get { return m_fuelType; }
            set { m_fuelType = value; }
        }
    }
}

In my Lite Model I only want to expose the speed:

using Model;

namespace ModelLite
{
    public class Car
    {
        private Model.Car car = new Model.Car();

        public double Speed
        {
            get { return this.car.Speed; }
            set { this.car.Speed = value; }
        }

    }
}

Since the model is big this involves in a lot of duplication. Maybe there is a better alternative?

Thanks

+2  A: 

There is no solution to this problem. If different devs are only allowed to have partial access to fields, you will need to create different feeds for different devs.


Although your model just seems wrong to me, you might however accomplish this by:

  • Creating one feed object that has all the properties the main object also has
  • Create some attribute like:

 class FeedSecurityAttribute : Attribute  
 {   
       public FeedSecurityAttribute(params string[] rights) {}  
 }

  • Add annotations on the properties of the feed specifying who has access to this property like [FeedSecurity("piet", "klaas")] string MyProperty { get;set; }
  • Fill your feed object from a business object automatically using some reflection and expression trees, and check whether the user has access to the property, otherwise ignore it.
Jan Jongboom
+2  A: 

Take a look at the work by Martin Fowler on Application Facades and the Facade Pattern

Stephan Eggermont
I think the link for Application Facades should be http://martinfowler.com/apsupp/appfacades.pdf
Kane
Changed. Thank you.
Stephan Eggermont
A: 

You could may be look at using multiple interfaces

public interface ICarBasic
{
    double Speed { get; set; }
}

public interface ICar : ICarBasic
{
    FuelType FuelType { get; set; } 
}

Or Write all your Basic object as base classes. Inherit from them to make the full classes using a new assembly. Giving the developers out side the project only the assembly with the base classes in might solv your issue.

Assembly 1 (For the other Devs)

using Model;         

namespace ModelLite         
{         
    public class Car         
    {         
        private Model.Car car = new Model.Car();         

        public double Speed         
        {         
            get { return this.car.Speed; }         
            set { this.car.Speed = value; }         
        }         

    }         
}    

Assembly 2 (Fully Featured)

using ModelLite

namespace Model          
{          
    public class Car : ModelLite.Car         
    {          
        private FuelType m_fuelType;          

        public FuelType FuelType          
        {          
            get { return m_fuelType; }          
            set { m_fuelType = value; }          
        }          
    }          
}     

Only give assembly 1 to the other developers.

Nanook
This is basically what Tarscher says in his first post. This is unmaintainable when you'll need to support this for > X different feed versions.
Jan Jongboom
The original post was the other way around. He was implementing speed twice. My suggestion only has it once. And since when has Inheritence been unmaintainable?
Nanook
It's unmaintainable if you have `class Car { Model; Year; Fuel; }` and want to expose `Model; Year;` to one person, `Fuel; Model;` to another, and `Year; Fuel;` to someone else.
Jan Jongboom