-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IModel #55
Comments
As we're working with entities I would go with: public interface IEntity { }
public interface IEntity<TId> : IEntity
{
public TId Id { get; set; }
} Also pretty sure you can derive your model from that interface and it should just work in it's current form. |
Sure, that would be better. |
Thinking this through... if this interface was implemented by a class and a collection, how do you see this applying to the APIs? This feels like it plays in the same space as the #4 Repository support. Thoughts? |
Yeah I would agree this kind of falls into repository pattern territory |
Yeah, I think this is the same thing as Repository support. This (or repository support) would allow the client/user to get a compilation error if their Model does not contain an |
It might be nice if the user was allowed to inherit their model from an
IModel
interface that looked something like this:This would allow the code not to have to use the
Type.GetProperty()
method and provide more IntelliSense.The text was updated successfully, but these errors were encountered: