I want to assign two classes to generic constraint at runtime using an OR condition. I don't know if it is possible or not, as I am relatively new to all this.
public interface IGenericRepository<TEntity> where TEntity : Employee Department
I want to assign TEntity either Employee class or Department class. Employee & Department are my two entities in DbContext. Please help me out on this one. Thank you in advance.
My first recommendation is: Do not use another generic repository on top of Entity Framework, because it already implements one.
In the other hand, I have seen cases where this make sense. If you are in one of those cases, consider using Generic Repository only for the things that you could apply to every single class of your model. As soon as your model object requires an special query, then create it's own repository for it.
for example, it might be that for Department you only do a ListAll(), then use a generic repository.
But let's imagine that for employee you might want to do more complex things, like ListAllEmployessUnderBossThatAreOnHolidays(Employee boss)
Then you could have this structure:
// All model classes inherit from this one
public class ModelObject
{}
public class Employee: ModelObject
{}
public class Department: ModelObject
{}
// This repository could be use for simple model objects that do simple operations
// For example, -ALL- Department operations are simple, and it never requires a
// complex query. So i handle it with this repository to avoid code duplication with
// other model objects that are also simple
public class IGenericRepository<TEntity> where TEntity : ModelObject
{ }
// Employee has some complex queries, so I create a repository for it that might or
// might not inherit from IGenericRepository
public class EmployeeRepository : IGenericRepository<Employee>
{ }
Related
we have a NHibernate Entity called Order. The Order has a List of Positions and some other stuff.
I now implemented a new Entity called OrderMin, which is now a base class of the Order. The same I did for the OrderPosition, which has now a base class called OrderPositionMin
When I try to load an OrderMin-Collection, I get a strange behavior:
In the collection, there are now OrderMin and Order objects, this is my Code:
var mins = Session.QueryOver<OrderMin>()
.Where(x => RestrictionExtensions.IsIn(x.Id,
list))
.List();
When I take a look in the collection, the containing Order objects has now 2 Lists Positions Lists. One is from the type OrderPosition and one from OrderPositionMin.
I tried to use the override keyword in the Order Object, but this is not possible due all Properties must be virtual.
Does anyone have an idea what's going wrong here?
Thanks in advance,
Dennis
This is a default behavior in NHibernate. You need to declare a base class from which your Order and OrderMin derive.
public abstract class OrderBase
{
// The properties that are needed by all derived types
}
public class OrderMin : OrderBase {}
public class Order : OrderBase {}
After that, your query result should look like you expect it.
If you query a base class, NHibernate will materialize all entities of the base class and all entities of the derived types.
I was playing around with the following quick tutorial to add a repo layer to my MVC4 app. Well I got everything going good eventually. Now I am trying to add a "domain / business" layer.
I am getting errors when I try but they are not the problem I want to ask. Esentially. What I need to know is what does the following code actually mean:
public class HeadRepo<TEntity> : IHeadRepository<TEntity> where TEntity : class
Specifically I am talking about the fact that I have declared an interface (I know what interfaces are and how they work) so here is the interface declaration:
public interface IHeadRepository<TEntity>
I am assuming that -TEntity- is a generic type and could even be called -XYZAnything- but the standard convention is -TWhatever-. The T prefix being important, perhaps I am wrong, if so please correct me.
When I implement this interface using the first line above. What is actually happening? Specifically what does the
where TEntity : class
actually do for me. This is the important part of the question as this is the part I don't understand and would like to know what phrases to google to learn more about it (some links would be cool).
Finally, I am trying to inherit from another class. I know the rules of inheritance fairly well. I can only inherit from a single class, but multiple interfaces etc. So when I add the following code:
public partial class Student : Model.Student, IHeadRepository<TEntity> where TEntity : class
and also this variant
public partial class Student : IHeadRepository<TEntity> where TEntity : class
Things should work, I am inheriting from the Model class auto generated by EF so I can extend it by adding properties and methods. Occasionally I am told that a property in the base class does not exist (I know exists in the base class and is public as it is EF auto generated, and I checked). So don't know why it does this, but more specifically I get this error on both attempts:
Constraints are not allowed on non-generic declarations
I am assuming this has something to do with the where TEntity : class bit (mostly because this is highlighted with a red underline). hence the question.
Any help would be much appreciated.
I am assuming that TEntity is a generic type and could even be called XYZAnything but the standard convention is TWhatever. The T prefix being important
That’s correct. IHeadRepository<TEntity> is a generic interface with the generic type parameter TEntity which is just a name you can choose freely to reference the concrete type. The prefix T is just a convention which you should also follow.
where TEntity : class is a constraint on the generic type parameter TEntity and essentially means that TEntity should be a reference type. The general syntax is TEntity : SomeType which means that TEntity needs to be a subtype of SomeType. There are three special cases:
where TEntity : class – TEntity needs to be a reference type (i.e. created with class Something)
where TEntity : struct – TEntity needs to be a value type (i.e. created with struct Something)
where TEntity : new() – TEntity needs to have a default constructor, so you can use new TEntity() to create an object of that type.
class Student : Model.Student, IHeadRepository<TEntity> where TEntity : class
The generic type constrait always belongs to the type definition, so in your case, the where TEntity : class belongs to the definition of class Student. But since Student is not a generic type, you cannot have a generic type constraint.
Instead, you want Student to implement the generic type IHeadRepository<TEntity> (which has that constraint), so you will have to figure out what generic type you want to insert in that case:
class Student : Model.Student, IHeadRepository<SomeFoo>
{ }
In that case SomeFoo is required to follow the constraint of TEntity, i.e. SomeFoo needs to be a reference type. But what you want to insert there depends on what the interface actually means and how Student is supposed to implement it.
Prefix T is not important, but as you pointed out, it is a convention generally followed. You may note that one may have generic classes with <T,U>, or <TKey,TValue>.. just depends on what makes most sense in the context to you.
where TEntity : class This line tells the compiler, that you expect the generic type <TEntity> to be only reference types. And not value types. For example, if you said `HeadRepo, compiler will not allow it.
Typically when you want to add functionality to EF generated entity classes, you do not extend them (you could, in certain scenarios), but the classes generated by EF framework are partial classes.. Hence you could just declare your models partial class in another file, where you could add additional properties and methods etc.. This way EF will recognize your model class vs it not having any awareness of your new derived class.
The problem with the code public partial class Student : Model.Student, IHeadRepository<TEntity> where TEntity : class, is that while you are declaring a concrete class student, you are implementing a Generic Interface on it.. That doesn't make sense, because a concrete class must be concrete, and on contrary, you are making it implement a Generic interface, without specifying concrete type for TEntity. Like I said, extending Model.Student is not the right approach here..
Do not declare a new Student class.. You want to create a partial class for the same same Student class, as defined in your Model namespace.
Constraints
where TEntity : class
means that TEntity has to be a class. Otherwise it might be a struct or something else.
Inheritance with constraints
public partial class Student : IHeadRepository<TEntity> where TEntity : class
If you want to use constraints here you have to do like
public partial class Student<TEntity> : IHeadRepository<TEntity> where TEntity : class
Otherwise you have to use a concrete class without any constraints like
public partial class Student : IHeadRepository<YOURCLASS>
Of course YOURCLASS has to meet the constraint and therefore must be a class.
I am new to Repository Pattern and trying to use it in my project. I have following entities in my project:
UserProfile
UserTypeA
UserTypeB
UserTypeC
I have 3 types of users and UserProfile containing the general information about all three of them like Password, UserName etc. There are many other entities also and each type of user have different type of relationship with other entities. Now i have decided to create the following repository pattern for this:
public class UserProfileRepository
{
....
}
public class UserTypeAReository: UserProfileRepository
{
.....
}
public class UserTypeBReository: UserProfileRepository
{
.....
}
public class UserTypeCReository: UserProfileRepository
{
.....
}
So i want to know is this (repository inheritance) comes under good practices OR is there any other better way to do this ??
EDIT
There is a 1 to 0..1 shared primary key relationship b/w UserProfile and (UserTypeA, UserTypeB and UserTypeC).
Depending on what you're trying to achieve, you can also use an Interface or an Abstract Class.
If you want all the classes to have a common contract, but the implementation of each method is different, then you can use an Interface, and this will give more flexibility since you have multiple interface inheritance v's singe class inheritance with C#.
With the Abstract class, you can set up the methods, along with an implementation, but allow the derived class to override the base implementation.
This SO post might also help: Interface vs Base class
I'm using partial classes. One class is generated from EntityFramework. Another class I generate myself so that I can implement an interface. The interface will be used so two libraries/assemblies will not know about each other but will be able to implement the common interface.
My custom interface declares property EntityCollection(ITimesheetLabors) but my EntityFramework generates EntityCollection(TimesheetLabors) so the compiler tells me that my class doesn't implement EntityCollection(ITimesheetLabors) which is understandable. However, what is the best method of making my partial class return the collection of interfaces I desire?
Should the get of my collection property of my partial class return a newly instantiated EntityCollection so that it can cast the concrete types to my interface? It seems a bit of overkill. What am I missing?
public interface ITimesheet //My Interface
{
EntityCollection<ITimesheetLabors> Timesheets {get;set;}
}
public partial class Timesheet//Class generated by Entity Framework
{
EntityCollection<TimesheetLabors> Timesheets {get;set;}
}
public partial class Timesheet : ITimesheet //My Partial Class that implements my interface
{
EntityCollection<ITimesheetLabors> Timesheets {get;set;}
}
EF doesn't support interfaces so the only way is using both original property generated by EF and your interface property which will internally access the generated property.
Btw. your design smells - on the one side you are trying to hide your entities by using interfaces and in the same time you are exposing EntityCollection => you are making your upper layer dependent on EF. The common approach is to do the opposite design - hide EF and use POCOs (interfaces are usually not needed).
Would it be a good practice to implement entity base class like that:
[Serializable]
public abstract class Entity<T> : IComparable<Entity<T>>, IFormattable
{
public abstract Int32 CompareTo(Entity<T> entity);
public abstract String ToString(String format, IFormatProvider provider);
// ...
}
So all derived classes must implement those interfaces.
Is it reasonable to put IComparable<T> interface on entity class?
Thanks!
It's not a good (or bad) practice - it comes down entirely to your needs.
Specifying IComparable at such as general level comes with the risk that it may not make sense to compare some objects further down in the inheritance chain. Even if you can compare two objects, would it always make sense to? You may be requiring lines of code to be written to satify a contract which would never be used - beware of YAGNI circumstances.
However, this would be fine if you need to create an absolute contract so that any objects inheriting from Entity can be compared. This allows you to make positive assumptions in your code.
What would T be? Your domain class? If that's the case why not make the Entity class non-generic and directly inherit from Entity?
In general, I've found it to be a good practice to derive all domain classes that can be handled by a particular Repository from a common interface or base class. This allows the Repository to be generic to that interface, providing compile-time checking that you are attempting to use the Repository to persist something that the Repository has mapped. If you use a base class, though, don't map it unless you need a way to uniquely identify any Entity regardless of its actual subclass type; otherwise you'll get that Entity table (with any common fields) as a table in your DB and it can become difficult to manually trace through your data layer.
However, a common, mapped Entity may be desireable; you may want to uniquely identify Persons and Companies by a common ID column that is unique even through Persons and Companies are saved to different tables.
Here's a sterilized example of the hierarchy I've used in one of my projects:
//identifies a class as persistable, and requires the class to specify
//an identity column for its PK
public interface IDomainObject { long Id {get;} }
//In a repository-per-DB model, just because it's an IDomainObject doesn't mean
//a repo can work with it. So, I derive further to create basically "marker"
//interfaces identifying domain objects as being from a particular DB:
public interface ISecurityDomainObject:IDomainObject { }
public interface IDataDomainObject:IDomainObject { }
public interface IData2DomainObject:IDomainObject { }
//There may be logic in your repo or DB to prevent certain concurrency issues.
//You can specify that a domain object has the necessary fields for version-checking
//either up at the IDomainObject level, a lower level, or independently:
public interface IVersionedDomainObject:IDomainObject
{
long Version {get;}
string LastUpdatedBy {get;}
DateTime LastUpdatedDate {get;}
}
//Now, you can use these interfaces to restrict a Repo to a particular subset of
//the full domain, based on the DB each object is persisted to:
public interface IRepository<TDom> where TDom:IDomainObject
{
//yes, GTPs can be used as GTCs
T GetById<T>(long Id) where T:TDom;
void Save<T>(T obj) where T:TDom;
//not only must the domain class for SaveVersioned() implement TRest,
//it must be versionable
void SaveVersioned<T>(T versionedObj) where T:TDom, IVersionedDomainObject
}
//and now you can close TDom to an interface which restricts the concrete
//classes that can be passed to the generic methods of the repo:
public class ISecurityRepo:IRepository<ISecurityDomainObject> { ... }
If your entities require comparability and formatting than using a base class is a very good practice.
sometimes the identity field is also implemented in the base class.