|
|
Ah, those are called "Shell namespace extensions". There's an example here[^], along with this warning:Editor's Update - 6/23/2006: Because shell extensions are loaded into arbitrary processes and because managed code built against one version of the runtime may not run in a process running an earlier version of the runtime, Microsoft recommends against writing managed shell extensions and does not consider them a supported scenario. A commercial alternative would be EzNamespaceExtensions[^], but the recommended way is still to use a non-managed language.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks You for Your help. 
|
|
|
|
|
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
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
|
|
|
|
|
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 a SqlTransaction. 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 coupling
Why, you planning on using other databases? A static class would suffice IMO; even if you DO use another database, you'd be changing the connectionstring, not the class.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Mohammad Dayyan wrote: <layer>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: <layer>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.
|
|
|
|
|
|
For a C# 2010 windows service I need to check to see if files exist in a speciifed directory location at specified time intervals. If file(s) exist in the specified location, I need to accomplish the following steps:
1. I need to call some specified code for updating the database,
2. I need to find a way to indicate the files where already accessed without moving the files from their original location.
3. I need to know how to setup the windows service.
Thus I am wondering if you can tell me and/or point me to a reference that will tell me how to accomplish my goal using a windows service? I could use a different utility if you think it is better than use a windows service.
|
|
|
|
|
2) You may be able to set an attribute, otherwise you may need to store the file info in the database
3) How frequently? If not very frequently, like ten minutes or more, then a Windows Scheduled Task may suffice.
|
|
|
|
|
You should look at FileSystemWatcher
dcof wrote: 2. I need to find a way to indicate the files where already accessed without moving the files from their original location.
I would say that sounds like a stupid requirement. If it was me I would question that.
But you can just record the file names in the database.
dcof wrote: 3. I need to know how to setup the windows service.
You can google that.
|
|
|
|
|
In a C# 2010 desktop application, I need to create a dynamic directory
paths based upon the names of some documents I obtain from a web service. Basically if the name of the file type in an xml file is called 'Customer Inventory", I need to place these documents in a folder one level lower than the rest of the documents. Basically most files will end up in a path that looks like:
C:\temp\customers.
However the files that are marked in the xml file called "Customer Inventory", need to end up in a file directory path that looks like the following: C:\temp\customers\Customer Inventory.
Thus can you tell me how I can create the correct directory paths I need to work with?
|
|
|
|
|
dcof wrote: Thus can you tell me how I can create the correct directory paths I need to work with?
Use the Directory.CreateDirectory[^]-method.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
|
My question is how can I place the files in one directory path or the second directory path that is longer? Basically the output files can go to 2 different locations. Can you tell or show me how to determine and actually place the different type of files in the different directory path locations?
|
|
|
|
|
This is all fairly basic stuff. What, exactly, is your background? How did you end up with this task? Judging by the number of questions you have posted recently, it seems that you are turning straight to Code Project for solutions.
|
|
|
|
|
I have 2 years of experience with C# and 1 year with VB. I only ask the simple questions here. I do not place the difficult questions here since I do not think that is what this message board is setup for.
|
|
|
|
|
So, how do you think you should solve this problem? Talk me through the problem and potential solutions. Break it down into little steps; you'll be surprised just how easy it is to solve when you know this.
|
|
|
|
|
Based on your other responses.
You were told how to create directories.
You already know the name of the file you must look for. If you don't then you MUST figure that out BEFORE you code.
So now that you know the name, from your example there is one name, so you use an 'if' to compare the name of the file to the file that you have.
So the pseudo code looks like
fileName = GetFileName()
if (fileName equals "Customer Inventory")
if (! Output dir)
CreateOutputDir()
WriteFileToInventoryDir()
else
WriteFileToMainDir
|
|
|
|
|
I am having a problem using linq to sql in a C# desktop application that connects to sql server 2008. Basically if the CustId already exists in the Trans table, I do not want to insert a new row into the table. However the code listed below does not work.
**Note the CustId is not the primary key of the table. there is an identity key that is the primary key of the table.
eDataContext rptData = new eDataContext();
var eupdate = (from a in rptData.Tran
where a.Cust_ID == CustId
select a).SingleOrDefault();
if (eupdate != null)
{
log.Info(CustId + "already exists in the Trans table");
}
else
{
Trans subCustid = null;
subCustid = new Trans();
subCustid.Package_ID = pkgid;
rptData.Trans.InsertOnSubmit(subCustid);
rptData.SubmitChanges();
}
Thus can you tell me what I can do to not allow a row to be inserted into the Trans table when the CustId already exists in the table?
|
|
|
|
|
In a C# 2010 desktop I have one solution file that have 4 separate project folders. In two of the project folders I need to access two of the same tables using linq to sql. I do not know how to make each project folder be aware of the two tables. Thus I embedded basically the same *.dbml files within each separate project folder.
I do not think what I did is the best solution. Due to this fact, I have the following questions:
1. Is there some kind of a way that each project folder can have access to the same *.dbml file? If you can you tell me how to accomplish this goal?
2. One of the project folders is a proxy file. Is it a good or bad idea to have a proxy class (project) folder update a *.dbml? Can you explain your answer to me?
|
|
|
|
|
The solution is to create a single library project that exposes the database as an object library.
Then both of the application projects can use this library and no worry abouy what you're asking about at all.
|
|
|
|
|
Can you show me code and/or point me to a link that will show me how to the code as you are just suggesting needs to occur?
|
|
|
|
|
Not really. It's a matter of thinking about the problem the correct way. Think about this... you're writing a library that interacts with the database. What do you have to expose in the way of methods and return types that any application you write can use that library and not worry about how the database is implemented at all??
Try getting a book on the Entity Framework and you'll see what I mean.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
