Is it OK to implement Repository Pattern with Singleton in C# and EntityFramework ?
-
As you know, in Entity Framework Repository Pattern we have new
DbContext(or object context)in each entity's instance. Is it OK to implement Repository Pattern with Singleton to have the same DbContext in each entity's instance? If so, could you please post some references ? Thanks Read more about Repository Pattern : http://www.remondo.net/repository-pattern-example-csharp/[^] -
As you know, in Entity Framework Repository Pattern we have new
DbContext(or object context)in each entity's instance. Is it OK to implement Repository Pattern with Singleton to have the same DbContext in each entity's instance? If so, could you please post some references ? Thanks Read more about Repository Pattern : http://www.remondo.net/repository-pattern-example-csharp/[^]Mohammad Dayyan wrote:
Is it OK to implement Repository Pattern
I haven't used the EF, but I'd assume that these "features" would already be in the implementation. What do you think you will gain from the added patterns that's not there in EF? And why do you want a singleton, and not a simple static class?
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
Mohammad Dayyan wrote:
Is it OK to implement Repository Pattern
I haven't used the EF, but I'd assume that these "features" would already be in the implementation. What do you think you will gain from the added patterns that's not there in EF? And why do you want a singleton, and not a simple static class?
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
Well :^) there are some reasons that you could find them with Google.
Eddy Vluggen wrote:
What do you think you will gain from the added patterns that's not there in EF?
my reasons : With Repository pattern we could hide DbContext(or ObjectContext) in UI layer for UI programmers and the they don't need to work with DbContext directly. otherwise, for each entity we have to write Update, Delete, Insert, ... methods. So with repository "Don't Repeat Yourself"
Eddy Vluggen wrote:
And why do you want a singleton, and not a simple static class?
Static class is an instance for all, and it has the same position in RAM of system. but Singleton has a static field and we can have different instances of our class, but we prevent coupling
-
Well :^) there are some reasons that you could find them with Google.
Eddy Vluggen wrote:
What do you think you will gain from the added patterns that's not there in EF?
my reasons : With Repository pattern we could hide DbContext(or ObjectContext) in UI layer for UI programmers and the they don't need to work with DbContext directly. otherwise, for each entity we have to write Update, Delete, Insert, ... methods. So with repository "Don't Repeat Yourself"
Eddy Vluggen wrote:
And why do you want a singleton, and not a simple static class?
Static class is an instance for all, and it has the same position in RAM of system. but Singleton has a static field and we can have different instances of our class, but we prevent coupling
Mohammad Dayyan wrote:
there are some reasons that you could find them with Google.
The answer to the question can probably also be found with a lot of Googeling. Like I said, I have no experience with the EF, just thought I'd try to formulate half an answer and see how far we could get, since the rest of the members seem to be stuck in the lounge. Easiest strategy to verify the idea is to have you convince me that your approach is the correct one; since you already have the arguments, that'd probably be easy. If one can explain the motivation behind a solution, they'll at least have considered and weighed all (known) options. No, that's not a guarantee that it's the most optimal solution, but it is an indication that it is a the most ideal at the time of implementation.
Mohammad Dayyan wrote:
With Repository pattern we could hide DbContext(or ObjectContext) in UI layer for UI programmers and the they don't need to work with DbContext directly.
That implies that they will bother you whenever there's a need for a change in the intermediate class. At a previous location, someone had the same bright idea on a
SqlConnection, killing the possibility of hooking up aSqlTransaction. If one learns to program, one should know what a IDbConnection is, and how to use it - hiding it had no extra value for us, only downsides. Convince yourself that such is not the case for your DbContext.Mohammad Dayyan wrote:
otherwise, for each entity we have to write Update, Delete, Insert, ... methods. So with repository "Don't Repeat Yourself"
Really? Looks like I won't be using EF for a while then, I don't like to do repetitive tasks that can be automated. Mostly because I'm known to make mistakes, and the computer does not. Doesn't the EF create "entities" to work on that translate into those kind of queries automatic? If not, you got a good point here, would be in violation of the DRY-principle.
Mohammad Dayyan wrote:
Static class is an instance for all, and it has the same position in RAM of system.
but Singleton has a static field and we can have different instances of our class, but we prevent couplingWhy, you planning on using other databases? A static class would suffice IMO; even if you DO use another database, you'd be changing the connecti
-
As you know, in Entity Framework Repository Pattern we have new
DbContext(or object context)in each entity's instance. Is it OK to implement Repository Pattern with Singleton to have the same DbContext in each entity's instance? If so, could you please post some references ? Thanks Read more about Repository Pattern : http://www.remondo.net/repository-pattern-example-csharp/[^]Mohammad Dayyan wrote:
Repository Pattern
Repository Pattern is just applying a new name to an old idiom - a database layer. And yes you should have a database layer.
Mohammad Dayyan wrote:
with Singleton to have the same DbContext in each entity's instance?
Is is ok to use a Singleton? I doubt it. (from your other post...)
otherwise, for each entity we have to write Update, Delete, Insert,
Reposit
Not sure what you think you are doing but you are going to need to do that regardless.
Mohammad Dayyan wrote:
Static class is an instance for all, and it has the same position in RAM of system. but Singleton has a static field and we can have different instances of our class, but we prevent coupling
As stated that is basically all wrong. First classes, not data, all exist as a single instance (again the class and not the class instance) in memory excluding AppDomains. Second in modern OSes the OS moves applications, everything including data, code and OS management stuff associated with application around all the time including moving it to the hard drive. So it can never be said to be in one place in the RAM. Third class instances (not the class this time) are managed by the C# heap and it can move them around in memory. So it won't even be in the same place in virtual memory. Fourth, although a Singleton has a rigid definition the conceptual idea of a 'single' instance can take many forms, including implementing access via a static class. Fifth, none of that has anything to do with coupling. I suspect that you should at least first attempt to write the Repository code. AFTER you complete that then you can consider the following 1. Are threads involved? 2. Is there any point to using a singleton? If the answer to the first is no and the answer to the second is yes then you can use a singleton.
-
Mohammad Dayyan wrote:
Repository Pattern
Repository Pattern is just applying a new name to an old idiom - a database layer. And yes you should have a database layer.
Mohammad Dayyan wrote:
with Singleton to have the same DbContext in each entity's instance?
Is is ok to use a Singleton? I doubt it. (from your other post...)
otherwise, for each entity we have to write Update, Delete, Insert,
Reposit
Not sure what you think you are doing but you are going to need to do that regardless.
Mohammad Dayyan wrote:
Static class is an instance for all, and it has the same position in RAM of system. but Singleton has a static field and we can have different instances of our class, but we prevent coupling
As stated that is basically all wrong. First classes, not data, all exist as a single instance (again the class and not the class instance) in memory excluding AppDomains. Second in modern OSes the OS moves applications, everything including data, code and OS management stuff associated with application around all the time including moving it to the hard drive. So it can never be said to be in one place in the RAM. Third class instances (not the class this time) are managed by the C# heap and it can move them around in memory. So it won't even be in the same place in virtual memory. Fourth, although a Singleton has a rigid definition the conceptual idea of a 'single' instance can take many forms, including implementing access via a static class. Fifth, none of that has anything to do with coupling. I suspect that you should at least first attempt to write the Repository code. AFTER you complete that then you can consider the following 1. Are threads involved? 2. Is there any point to using a singleton? If the answer to the first is no and the answer to the second is yes then you can use a singleton.
Thanks