I have an interface that represents a table in a 3rd party API. Each instance provides the ability to search a single table using forward-only cursors:
public interface ITable
{
string TableName { get; }
ICursor Search(string whereClause);
}
I have written a wrapper class to handle searching an ITable and returning an enumerable instead (it's a little more complex than that in reality, but sufficient for showing my issue):
public interface ITableWrapper
{
IEnumerable<object> Search(string whereClause);
}
public class TableWrapper : ITableWrapper
{
private ITable _table;
public TableWrapper(ITable table)
{
_table = table;
}
public IEnumerable<Row> Search(string whereClause)
{
var cursor = _table.Search(whereClause);
while(cursor.Next())
{
yield return cursor.Row;
}
}
}
I then have several repository classes that should have a table wrapper injected:
public class Table1Repository
{
private ITableWrapper _table;
public Table1Reposiroty(ITableWrapper table)
{
_table = table;
}
//repository methods to actually do things
}
Since each table will have its own wrapper, and repositories need the correct table injecting, my thought was to use named bindings on the tables and wrappers so that ninject provides the correct instance. Thus the above class would have NamedAttribute applied to the constructor argument, and the binding would be as follows:
public void NinjectConfig(IKernel kernel, ITableProvider provider)
{
Bind<ITable>().ToMethod(ctx => provider.OpenTable("Table1")).Named("Table1").InSingletonScope();
Bind<ITableWrapper>().ToMethod(ctx => new TableWrapper(ctx.ContextPreservingGet<ITable>("Table1"))).Named("Table1Wrapper").InSingletonScope();
}
My questions are:
Is there a cleaner way to express this binding? I was thinking maybe a way to bind ITableWrapper once and have a new instance returned for each named ITable, with the repository constructor parameter attribute picking the named ITable for which it wants the ITableWrapper.
If the ITable should never be used by anything, and everything should always use ITableWrapper, is it ok (or even recommended) to bind just ITableWrapper and have that combine both ToMethod contents:
public void NinjectConfig(IKernel kernel, ITableProvider provider)
{
Bind<ITableWrapper>().ToMethod(ctx => new TableWrapper(provider.OpenTable("Table1"))).Named("Table1Wrapper").InSingletonScope();
}
There's no Ninject-built-in way to provide metadata to Ninject by attribute. The only thing it supports is the ConstraintAttribute (and the NamedAttribute as a subclass). This can be used to select a specific binding, but it can't be used to provide parameters for a binding.
So, in case you don't want to add a lot of code, the easiest and most concise way is along of what you suggested yourself:
public static BindTable(IKernel kernel, ITableProvider tableProvider, string tableName)
{
kernel.Bind<ITableWrapper>()
.ToMethod(ctx => new tableWrapper(tableProvider.OpenTable(tableName))
.Named(tableName);
}
(I've used the same string-id here for both table name and ITableWrapper name - this way you don't need to map them).
Also, i think it's better not to create a binding for ITable if you're not going to use it, anyway.
note: If you were to create the ITableWrapper by a factory (instead of ctor-injecting it), you could use parameters and a binding which reads the table-id from the parameter. Meaning a single binding would suffice.
Generic Solution
Now in case you're ok with adding some custom code you can actually achieve a generic solution. How? you add a custom attribute to replace the NamedAttribute which provides the table name. Plus you create a binding which reads the table name from this custom attribute. Let's say:
[AttributeUsage(AttributeTargets.Parameter, AllowMultiple = false, Inherited = true)]
public class TableIdAttribute : Attribute
{
public TableIdAttribute(string tableName)
{
TableName = tableName;
}
public string TableName { get; private set; }
}
let's implement an IProvider to capsule the added binding complexity (it would also work with a ToMethod binding):
internal class TableWrapperProvider : Provider<ITableWrapper>
{
private readonly ITableProvider _tableProvider;
public TableWrapperProvider(ITableProvider tableProvider)
{
_tableProvider = tableProvider;
}
protected override ITableWrapper CreateInstance(IContext context)
{
var parameterTarget = context.Request.Target as ParameterTarget;
if (parameterTarget == null)
{
throw new ArgumentException(
string.Format(
CultureInfo.InvariantCulture,
"context.Request.Target {0} is not a {1}",
context.Request.Target.GetType().Name,
typeof(ParameterTarget).Name));
}
var tableIdAttribute = parameterTarget.Site.GetCustomAttribute<TableIdAttribute>();
if (tableIdAttribute == null)
{
throw new InvalidOperationException(
string.Format(
CultureInfo.InvariantCulture,
"ParameterTarget {0}.{1} is missing [{2}]",
context.Request.Target,
context.Request.Target.Member,
typeof(TableIdAttribute).Name));
}
return new TableWrapper(_tableProvider.Open(tableIdAttribute.TableName));
}
}
and here's how we use it (example classes):
public class FooTableUser
{
public FooTableUser([TableId(Tables.FooTable)] ITableWrapper tableWrapper)
{
TableWrapper = tableWrapper;
}
public ITableWrapper TableWrapper { get; private set; }
}
public class BarTableUser
{
public BarTableUser([TableId(Tables.BarTable)] ITableWrapper tableWrapper)
{
TableWrapper = tableWrapper;
}
public ITableWrapper TableWrapper { get; private set; }
}
and here's the bindings plus a test:
var kernel = new StandardKernel();
kernel.Bind<ITableProvider>().ToConstant(new TableProvider());
kernel.Bind<ITableWrapper>().ToProvider<TableWrapperProvider>();
kernel.Get<FooTableUser>().TableWrapper.Table.Name.Should().Be(Tables.FooTable);
kernel.Get<BarTableUser>().TableWrapper.Table.Name.Should().Be(Tables.BarTable);
Related
I implemented generic repository pattern and unitofwork. I used basic patterns and they work great. In project I have requirement which says, every table has several fields which contains long, really long text, and user should have ability chose and open any of it. As each field named differently i decided to use power ov generics with reflection, to write method which resieves table name and field name and returns it.
Method, in generic Repository class, i wrote looks like this, it seems work properly
public interface IRepository<T> where T : class
{
//other methods
string GetPropertyByName(int id, string property);
}
public class Repository<T> : IRepository<T> where T : class
{
// other methods. add, edit, delete...
public string GetPropertyByName(int id, string property)
{
T model = this.Get(id);
var obj = model.GetType().GetProperty(property).GetValue(model, null);
return obj != null ? obj.ToString() : null;
}
}
I creted model classes for tables with help EF. Some tables binds directly genric repository, while other have separate interface and its implementation, as they require additional method. Example:
public interface ICompanyRepo : IRepository<COMPANY>
{
//some methods
}
public class CompanyRepo : Repository<COMPANY>, ICompanyRepo
{
//implementations of interface methods
}
And UOW implementation:
public interface IUnitOfWork
{
ICompanyRepo Company { get; }
IRepository<CURRENCY> Currency { get; }
}
public class UnitOfWork : IUnitOfWork
{
static DBEntities _context;
private UZMEDEXPORTEntities context
{
get
{
if (_context == null)
_context = new DBEntities();
return _context;
}
}
public UnitOfWork()
{
_context = context;
Company = new SP_CompanyRepo();
Currency = new Repository<CURRENCY>();
}
public ICompanyRepo Company { get; private set; }
public IRepository<CURRENCY> Currency { get; private set; }
}
I have problem on invoking GetPropertyByName() method in business layer.
I tried this:
public string GetHistory(string tableName, string fieldName, int id)
{
var prop = unitOfWork.GetType().GetProperty(tableName);
MethodInfo method;
method = prop.PropertyType.GetMethod("GetPropertyByName"); //try to find method
if(method == null) //if method not found search for interface which contains that method
method = prop.PropertyType.GetInterface("IRepository`1").GetMethod("GetPropertyByName");
var res = method.Invoke(prop, new object[] { id, fieldName });
return (string)res;
}
Which returns System.Reflection.TargetException. As I understood the problem is whith unitofwork implementation. In my invoke method "prop" is type of interface (ICompanyRepo), but invoke's target should be interface implementation class, in this case "CompanyRepo".
I could not find how to identify type of implementetion class, and solve this problem. Any help is appropriated
I am not sure that this is best option, but problem solved with use of ToExpando() extension given here. With this extension i could loop throw all properties of unitofwork and find required property by its name.
var propValue = unitOfWork.ToExpando().Single(x => x.Key == prop.Name).Value;
var res = method.Invoke(propValue, new object[] { id, fieldName });
Now method is invoking properly. May be there is cleaner solution, and I still hope to find this. For now i am going to use this solution, and just realised that I must read and practice a lot about reflections, dynamics and generics.
P.S Special thanks to Alexei for important notes and advices
I'm working with MEF. And I was watching the demo called MVVM RI from PRISM, and a part of the program has this code:
/// <summary>
/// Factory class to create a question view model for a given question object.
/// </summary>
private static class QuestionViewModelFactory
{
private static Dictionary<Type, Func<Question, QuestionViewModel>> maps = new Dictionary<Type, Func<Question, QuestionViewModel>>()
{
{ typeof(OpenQuestion), (q) => new OpenQuestionViewModel((OpenQuestion)q) },
{ typeof(MultipleSelectionQuestion), (q) => new MultipleSelectionQuestionViewModel((MultipleSelectionQuestion)q) },
{ typeof(NumericQuestion), (q) => new NumericQuestionViewModel((NumericQuestion)q) }
};
public static QuestionViewModel GetViewModelForQuestion(Question question)
{
Func<Question, QuestionViewModel> viewModelInstanceFactory = null;
if (maps.TryGetValue(question.GetType(), out viewModelInstanceFactory))
{
return viewModelInstanceFactory(question);
}
else
{
throw new ArgumentOutOfRangeException("Could not locate a view model for question type");
}
}
}
// Note that each class derived QuestionViewModel needs a constructor parameter to be created.
public abstract class QuestionViewModel : NotificationObject
{
protected QuestionViewModel() { ... }
}
public abstract class QuestionViewModel<T> : QuestionViewModel
where T : Question
{
protected QuestionViewModel(T question) { ... }
}
In my software, I need this functionality, but now I'd like to do by discovery.
At the beginning, I was thinking to create a custom export to store only QuestionViewModel and to store as contractName the question type model. Check this.
[MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
public class ExportViewModelForProblemAttribute : ExportAttribute
{
public ExportViewModelForProblemAttribute(Type viewModelType, Type questionType)
: base(questionType.ToString(), typeof(QuestionViewModel))
{
}
}
But then I said, how can I pass the the object by the constructor? The idea is to pass the object q without using Import. But I got lost at this part.
public class ProblemViewModelFactory
{
private readonly CompositionContainer container;
[ImportingConstructor]
public ProblemViewModelFactory(CompositionContainer container)
{
this.container = container;
}
public QuestionViewModelFactory GetQuestionViewModelFactory(Question question)
{
// what can I do to return the correspond view model with the question inside?
}
}
What can I do to implement this mapping and pass the argument?
Thanks in advance.
With the Silverlight variant of MEF, we can include a type called the ExportFactory<T, TMetadata>. What this type does, is spin up a new instance of the type each time we call CreateExport() on it, but it also includes some additional information (metadata) about the part.
Now, what you are currently doing is exporting your question view models using the question name as the contract name. This won't make it easy to get instances of all QuestionViewModel types, so rather than that, you should continue to export as QuestionViewModel and append some metadata to the type, so in this case, you need a name property, so we can define our metadata contract as:
public interface INameMetadata
{
string Name { get; }
}
Now, let's make a modification to the export attribute:
[AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
[MetadataAttribute]
public class ExportQuestionAttribute : ExportAttribute, INameMetadata
{
public ExportQuestionAttribute(string name)
: base(typeof(QuestionViewModel))
{
this.Name = name;
}
public string Name { get; private set; }
}
I've changed the export attribute type to call the base constructor with only the type argument, and instead, store the value of name in a property Name. You don't actually need to decorate your export attribute with our metadata contract INameMetadata, but I prefer to as it ensures that when I am exporting, I get the compile time checking that I am providing all the required metadata.
Next, we can make a modification to our consumer type:
[Export]
public class ProblemViewModelFactory
{
private readonly IEnumerable<ExportFactory<Question, INameMetadata>> _questionFactories;
[ImportingConstructor]
public ProblemViewModelFactory(
[ImportMany] IEnumerable<ExportFactory<Question, INameMetadata>> questionFactories)
{
if (questionFactories == null)
throw new ArgumentNullException("questionFactories");
_questionFactories = questionFactories;
}
public QuestionViewModel GetQuestionViewModel(string name)
{
return _questionFactories
// Get matching question factories
.Where(q => q.Metadata.Name == name)
// Select the exported value
.Select(q => q.CreateExport().Value)
// First or default - what if the question doesn't exist?
.FirstOrDefault();
}
}
Now, we've modified this part in a couple of ways.
First, we only accept an instance of an IEnumerable<ExportFactory<QuestionViewModel, INameMetata>>, which is our collection of part factories. This should contain factories for every type of question that has been exported. The import part is the GetQuestionViewModel method (which I am assuming you wanted to return QuestionViewModel, not QuestionViewModelFactory). The ExportFactory type does the work of spinning up a new instance, and because it is of a type ExportFactory<QuestionViewModel, INameMetadata>, it has a Metadata property that is of type INameMetadata that we can query before we create our part.
The last method will query the set of available factories, checking the Name property of each INameMetadata instance, and returning that question which matches, or null if one cannot be found. It will also ignore multiple questions with the same name, and select only the first (this design decision will be up to you).
I hope that points you in the right direction.
How can i check/evaluate the exact type of T without an object for T. I know my question maybe confusing but consider this...
public abstract class Business
{
public abstract string GetBusinessName();
}
public class Casino : Business
{
public override string GetBusinessName()
{
return "Casino Corp";
}
}
public class DrugStore : Business
{
public override string GetBusinessName()
{
return "DrugStore business";
}
}
public class BusinessManager<T> where T : Business
{
private Casino _casino;
private DrugStore _drugStore;
public string ShowBusinessName()
{
string businessName;
if (T == Casino) // Error: How can I check the type?
{
_casino = new Casino();
businessName = _casino.GetBusinessName();
}
else if (T == DrugStore) // Error: How can I check the type?
{
_drugStore = new DrugStore();
businessName = _drugStore.GetBusinessName();
}
return businessName;
}
}
I just want to have something like this on the client.
protected void Page_Load(object sender, EventArgs e)
{
var businessManager = new BusinessManager<Casino>();
Response.Write(businessManager.ShowBusinessName());
businessManager = new BusinessManager<DrugStore>();
Response.Write(businessManager.ShowBusinessName());
}
Notice that I actually didnt create the actual object for Casino and Drugstore when I call the BusinessManager, I just pass it as generic type constraint of the class. I just need to know exactly what Type i am passing BusinessManager to know what exactly the Type to instantiate. Thanks...
PS: I don't want to create separate specific BusinessManager for Casino and Drugstore..
You can also comment about the design.. thanks..
ADDITIONAL: and what if class Casino and DrugStore is an ABSTRACT CLASS =)
You can write
if(typeof(T) == typeof(Casino))
but really this type of logic is a code smell.
Here's one way around this:
public class BusinessManager<T> where T : Business, new() {
private readonly T business;
public BusinessManager() {
business = new T();
}
}
but personally I'd prefer
public class BusinessManager<T> where T : Business {
private readonly T business;
public BusinessManager(T business) {
this.business = business;
}
public string GetBusinessName() {
return this.business.GetBusinessName();
}
}
You should do
public class BusinessManager<T> where T : Business, new()
...
T _business = new T();
string businessName = _business.GetBusinessName();
return businessName;
I don't know about C# syntax, but is it not possible to do:
public class BusinessManager<T> where T : Business, new()
{
private T _business;
public string ShowBusinessName()
{
string businessName;
_business = new T();
return _business.GetBusinessName();
}
}
Since other guys have already shown various answers to your first question, I would like to address the second one: design.
1. Role of BusinessManager
Actual role of the BusinessManager class in your example is not too clear. Since this class is generic, and it shouldn't be concerned with the actual type of T, then it does nothing more than add another unnecessary layer between the Business class and the rest of the program.
In other words, you can simply use:
Business casino = new Casino();
Response.Write(casino.GetBusinessName());
Business drugStore = new DrugStore();
Response.Write(drugStore.GetBusinessName());
Wrapping this in another generic class doesn't help you a lot. On the other hand, if you want to have some common functionality for all these classes, you can either add it directly to your abstract class, or extract an interface and create extension methods for that interface.
2. Using properties for getters
Second thing, using a property is more appropriate when you have a simple getter method. In other words, you should replace GetBusinessName() method with a Name property (I also omitted the "Business" from the name because it is not necessary:
public interface IBusiness
{
string Name { get; }
}
public abstract class Business : IBusiness
{
public abstract string Name { get; }
}
public class Casino : Business
{
public override string Name
{
get { return "Casino Corp"; }
}
}
public class DrugStore : Business
{
public override string Name
{
get { return "DrugStore business"; }
}
}
And then you can use it like this:
IBusiness casino = new Casino();
Response.Write(casino.Name);
IBusiness drugStore = new DrugStore();
Response.Write(drugStore.Name);
Also, you can see that I have introduced a IBusiness interface. The reason for doing so is to allow you to implement this interface in more diverse ways. Right now, you will try to derive all your classes from the abstract Business class, and try to extract as much of the common functionality in the abstract class (that's the purpose of the class).
But extracting lots of common functionality comes with a cost: there is always a possibility that you will come up with a need to create a class which isn't derived from Business. If you are accessing all these methods through the IBusiness interface, then other parts of your program won't care if that implementation is derived from Business or not.
Since GetBusinessName really applies to the type and not instances of the type, you might consider using DescriptionAttribute (or your own BusinessNameAttribute) instead of an overridden property and have your BusinessManager get the business name from the attribute.
[Description("Casino Corp")]
public class Casino : Business
{
}
Now you no longer need to instantiate the business just to gets its name. To get the description, you use:
public string ShowBusinessName()
{
var attribute = Attribute.GetCustomAttribute(typeof(T), typeof(DescriptionAttribute)) as DescriptionAttribute;
if (attribute == null)
return "Unknown business";
return attribute.Description;
}
You can do something like this:
if (typeof(T) == typeof(SomeType))
{
// Same
}
define a BusinessManager class as bellow:
public class BusinessManager<T> where T : Business
{
Business biz;
public BusinessManager()
{
biz = new T();
}
public string ShowBusinessName()
{
return biz.GetBusinessName();
}
}
and use it as bellow:
var businessManager = new BusinessManager<Casino>();
Response.Write(businessManager.ShowBusinessName());
var anotherBusinessManager = new BusinessManager<DrugStore>();
Response.Write(businessManager.ShowBusinessName());
The way you using you will lost encapsulation
In VB.net you can use the GetType pseudo-function on a generic type parameter to get a reflection Type object. I would guess C# should have an equivalent. If for whatever reason you can't use something like that, you could create an array of 0 elements of the desired type, and then check the type of that array. That would probably be cheaper than instantiating an element of the unknown type.
In my current project I need to be able to have both editable and read-only versions of classes. So that when the classes are displayed in a List or PropertGrid the user is not able to edit objects they should not be allowed to.
To do this I'm following the design pattern shown in the diagram below. I start with a read-only interface (IWidget), and then create an edtiable class which implements this interface (Widget). Next I create a read-only class (ReadOnlyWidget) which simply wraps the mutable class and also implements the read only interface.
I'm following this pattern for a number of different unrelated types. But now I want to add a search function to my program, which can generate results that include any variety of types including both mutable and immutable versions. So now I want to add another set of interfaces (IItem, IMutableItem) that define properties which apply to all types. So IItem defines a set of generic immutable properties, and IMutableItem defines the same properties but editable. In the end a search will return a collection of IItems, which can then later be cast to more specific types if needed.
Yet, I'm not sure if I'm setting up the relationships to IMutable and IItem correctly. Right now I have each of the interfaces (IWidget, IDooHickey) inheriting from IItem, and then the mutable classes (Widget, DooHickey) in addition also implement IMutableItem.
Alternatively, I was also thinking I could then set IMutableItem to inherit from IItem, which would hide its read-only properties with new properties that have both get and set accessors. Then the mutable classes would implement IMutableItem, and the read-only classes would implement IItem.
I'd appreciate any suggestions or criticisms regarding any of this.
Class Diagram
Code
public interface IItem
{
string ItemName { get; }
}
public interface IMutableItem
{
string ItemName { get; set; }
}
public interface IWidget:IItem
{
void Wiggle();
}
public abstract class Widget : IWidget, IMutableItem
{
public string ItemName
{
get;
set;
}
public void Wiggle()
{
//wiggle a little
}
}
public class ReadOnlyWidget : IWidget
{
private Widget _widget;
public ReadOnlyWidget(Widget widget)
{
this._widget = widget;
}
public void Wiggle()
{
_widget.Wiggle();
}
public string ItemName
{
get {return _widget.ItemName; }
}
}
public interface IDoohickey:IItem
{
void DoSomthing();
}
public abstract class Doohickey : IDoohickey, IMutableItem
{
public void DoSomthing()
{
//work it, work it
}
public string ItemName
{
get;
set;
}
}
public class ReadOnlyDoohickey : IDoohickey
{
private Doohickey _doohicky;
public ReadOnlyDoohickey(Doohickey doohicky)
{
this._doohicky = doohicky;
}
public string ItemName
{
get { return _doohicky.ItemName; }
}
public void DoSomthing()
{
this._doohicky.DoSomthing();
}
}
Is it OK to create another object when you need a readonly copy? If so then you can use the technique in the included code. If not, I think a wrapper is probably your best bet when it comes to this.
internal class Test
{
private int _id;
public virtual int ID
{
get
{
return _id;
}
set
{
if (ReadOnly)
{
throw new InvalidOperationException("Cannot set properties on a readonly instance.");
}
}
}
private string _name;
public virtual string Name
{
get
{
return _name;
}
set
{
if (ReadOnly)
{
throw new InvalidOperationException("Cannot set properties on a readonly instance.");
}
}
}
public bool ReadOnly { get; private set; }
public Test(int id = -1, string name = null)
: this(id, name, false)
{ }
private Test(int id, string name, bool readOnly)
{
ID = id;
Name = name;
ReadOnly = readOnly;
}
public Test AsReadOnly()
{
return new Test(ID, Name, true);
}
}
I would suggest that for each main class or interface, there be three defined classes: a "readable" class, a "changeable" class, and an "immutable" class. Only the "changeable" or "immutable" classes should exist as concrete types; they should both derive from an abstract "readable" class. Code which wants to store an object secure in the knowledge that it never changes should store the "immutable" class; code that wants to edit an object should use the "changeable" class. Code which isn't going to write to something but doesn't care if it holds the same value forever can accept objects of the "readable" base type.
The readable version should include public abstract methods AsChangeable(), AsImmutable(), public virtual method AsNewChangeable(), and protected virtual method AsNewImmutable(). The "changeable" classes should define AsChangeable() to return this, and AsImmutable to return AsNewImmutable(). The "immutable" classes should define AsChangeable() to return AsNewChangeable() and AsImmutable() to return this.
The biggest difficulty with all this is that inheritance doesn't work terribly well if one tries to use class types rather than interfaces. For example, if one would like to have an EnhancedCustomer class which inherits from BasicCustomer, then ImmutableEnhancedCustomer should inherit from both ImmutableBasicCustomer and ReadableEnhancedCustomer, but .net doesn't allow such dual inheritance. One could use an interface IImmutableEnhancedCustomer rather than a class, but some people would consider an 'immutable interace' to be a bit of a smell since there's no way a module that defines an interface in such a way that outsiders can use it without also allowing outsiders to define their own implementations.
Abandon hope all ye who enter here!!!
I suspect that in the long run your code is going to be very confusing. Your class diagram suggests that all properties are editable (or not) in a given object. Or are your (I'm)mutable interfaces introducing new properties that are all immutable or not, separate from the "core"/inheriting class?
Either way I think you're going to end up with playing games with property name variations and/or hiding inherited properties
Marker Interfaces Perhaps?
Consider making all properties in your classes mutable. Then implement IMutable (I don't like the name IItem) and IImutable as a marker interfaces. That is, there is literally nothing defined in the interface body. But it allows client code to handle the objects as a IImutable reference, for example.
This implies that either (a) your client code plays nice and respects it's mutability, or (b) all your objects are wrapped by a "controller" class that enforces the given object's mutability.
Could be too late :-), but the cause "The keyword 'new' is required on property because it hides property ..." is a bug in Resharper, no problem with the compiler. See the example below:
public interface IEntityReadOnly
{
int Prop { get; }
}
public interface IEntity : IEntityReadOnly
{
int Prop { set; }
}
public class Entity : IEntity
{
public int Prop { get; set; }
}
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
var entity = new Entity();
(entity as IEntity).Prop = 2;
Assert.AreEqual(2, (entity as IEntityReadOnly).Prop);
}
}
Same for the case without interfaces. The only limitation, you can't use auto-properties
public class User
{
public User(string userName)
{
this.userName = userName;
}
protected string userName;
public string UserName { get { return userName; } }
}
public class UserUpdatable : User
{
public UserUpdatable()
: base(null)
{
}
public string UserName { set { userName = value; } }
}
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
var user = new UserUpdatable {UserName = "George"};
Assert.AreEqual("George", (user as User).UserName);
}
}
I'm creating a series of builders to clean up the syntax which creates domain classes for my mocks as part of improving our overall unit tests. My builders essentially populate a domain class (such as a Schedule) with some values determined by invoking the appropriate WithXXX and chaining them together.
I've encountered some commonality amongst my builders and I want to abstract that away into a base class to increase code reuse. Unfortunately what I end up with looks like:
public abstract class BaseBuilder<T,BLDR> where BLDR : BaseBuilder<T,BLDR>
where T : new()
{
public abstract T Build();
protected int Id { get; private set; }
protected abstract BLDR This { get; }
public BLDR WithId(int id)
{
Id = id;
return This;
}
}
Take special note of the protected abstract BLDR This { get; }.
A sample implementation of a domain class builder is:
public class ScheduleIntervalBuilder :
BaseBuilder<ScheduleInterval,ScheduleIntervalBuilder>
{
private int _scheduleId;
// ...
// UG! here's the problem:
protected override ScheduleIntervalBuilder This
{
get { return this; }
}
public override ScheduleInterval Build()
{
return new ScheduleInterval
{
Id = base.Id,
ScheduleId = _scheduleId
// ...
};
}
public ScheduleIntervalBuilder WithScheduleId(int scheduleId)
{
_scheduleId = scheduleId;
return this;
}
// ...
}
Because BLDR is not of type BaseBuilder I cannot use return this in the WithId(int) method of BaseBuilder.
Is exposing the child type with the property abstract BLDR This { get; } my only option here, or am I missing some syntax trick?
Update (since I can show why I'm doing this a bit more clearly):
The end result is to have builders that build profiled domain classes that one would expect to retrieve from the database in a [programmer] readable format. There's nothing wrong with...
mock.Expect(m => m.Select(It.IsAny<int>())).Returns(
new Schedule
{
ScheduleId = 1
// ...
}
);
as that's pretty readable already. The alternative builder syntax is:
mock.Expect(m => m.Select(It.IsAny<int>())).Returns(
new ScheduleBuilder()
.WithId(1)
// ...
.Build()
);
the advantage I'm looking for out of using builders (and implementing all these WithXXX methods) is to abstract away complex property creation (automatically expand our database lookup values with the correct Lookup.KnownValues without hitting the database obviously) and having the builder provide commonly reusable test profiles for domain classes...
mock.Expect(m => m.Select(It.IsAny<int>())).Returns(
new ScheduleBuilder()
.AsOneDay()
.Build()
);
All I can say is that if there is a way of doing it, I want to know about it too - I use exactly this pattern in my Protocol Buffers port. In fact, I'm glad to see that someone else has resorted to it - it means we're at least somewhat likely to be right!
I know this is an old question, but I think you can use a simple cast to avoid the abstract BLDR This { get; }
The resulting code would then be:
public abstract class BaseBuilder<T, BLDR> where BLDR : BaseBuilder<T, BLDR>
where T : new()
{
public abstract T Build();
protected int Id { get; private set; }
public BLDR WithId(int id)
{
_id = id;
return (BLDR)this;
}
}
public class ScheduleIntervalBuilder :
BaseBuilder<ScheduleInterval,ScheduleIntervalBuilder>
{
private int _scheduleId;
// ...
public override ScheduleInterval Build()
{
return new ScheduleInterval
{
Id = base.Id,
ScheduleId = _scheduleId
// ...
};
}
public ScheduleIntervalBuilder WithScheduleId(int scheduleId)
{
_scheduleId = scheduleId;
return this;
}
// ...
}
Of course you could encapsulate the builder with
protected BLDR This
{
get
{
return (BLDR)this;
}
}
This is a good implementation strategy for C#.
Some other languages (can't think of name of research language I've seen this in) have type systems that either support a covariant "self"/"this" directly, or have other clever ways to express this pattern, but with C#'s type system, this is a good (only?) solution.