|
Brady Kelly wrote: For authorization, I have interpreted this so that a user higher up in the user tree has access to all users below them in the tree, as well as entities owned by those lower users. This seems logical to me, as a user higher in the tree 'owns' users lower down.
I don't find that logical. If I were a node in your tree, I'd only pay attention to my parent - the topnode would never be relevant in my work. That's based on the idea of a "chain of command". If my bosses' boss could manage me directly, my boss would be superfluous. Better to check with the client whether your interpretation is correct.
Brady Kelly wrote: My client is unclear on what he wants here and expects some assistance in deriving a practical authorization scheme for this hierarchical user scheme.
"Authorization"? You mean the top-dog could login using my credentials?? There's bears down that road; it messes up audits.
Brady Kelly wrote: This preserves the higher privilege of higher users, but prevents a more senior user creating customers for more junior users to work on.
Not per se; just make sure that the junior is "part of" the group working on the customer 
|
|
|
|
|
Thanks, I'm slowly discarding big parts of my original concept, and moving toward the tree just representing the org, and everyone in the org (in the tree) having access to everything else in the tree, but limited by user roles.
Eddy Vluggen wrote: "Authorization"? You mean the top-dog could login using my credentials?? There's bears down that road; it messes up audits.
Authorization doesn't involve logins, Authentication does.
|
|
|
|
|
Brady Kelly wrote: Authorization doesn't involve logins, Authentication does.
Yesyes, you're right. I mixed them up.
|
|
|
|
|
I am using MEF in my application. My application have 4 parts(class library) and a main module , the main modules responsibility is to interact with the above said parts and delegates job to them.
I have coded all the interface and abstract base classes in a library called 'Common' and refer it to all the other dlls which have classes inherit from those base classes. I moved all the base class and interface definition to the 'Common' library so that i can add reference of that dll in my main program and all the base classes and interfaces are readily available.
Is this the right way to do it? What is the other option in MEF using which i can refer to the base classes in my main module without referring to a dll.
eg:- abstract class baseAbc and interface IAbc is defined in common.dll, Is it possible to refer baseAbc and IAbc in my main module without adding reference to Common.dll
|
|
|
|
|
Disclaimer; I don't use MEF.
John T.Emmatty wrote: Is this the right way to do it?
Sounds like "yes" to me; that way you can update both common/exe without touching the other.
John T.Emmatty wrote: What is the other option in MEF using which i can refer to the base classes in my main module without referring to a dll.
Don't know if the option exists; but it "would" generate classes, and it should be possible to reference/copy those to your own assembly. I expect this is not the recommended way.
What's against having a second assembly?
|
|
|
|
|
I'm currently given a project on hand gesture recognition. Some color markers will be put on the fingers for easy tracking.
So, can anyone give some advice how should I continue for the next part which is to recognize the pre-processed output image which is now only consists of color from the color markers. How can I classified those pattern.
|
|
|
|
|
Member 9169887 wrote: I'm currently given a project on hand gesture recognition. Some color markers will be put on the fingers for easy tracking.
So, can anyone give some advice how should I continue for the next part which is to recognize the pre-processed output image which is now only consists of color from the color markers. How can I classified those pattern.
I imagine the hard part would be to figure out where a specific command begins, and when it ends. Make a mask of the pattern, compare the mask to known masks using fuzzy logic. The one that fits best, is probably the one intended by the user.
|
|
|
|
|
Hi,
I have a usercontrol in my WPF application, and there is a code behind file suppose EmployeeEditor.xaml.cs which has some code to modify.
For e.g;
I have a Employee as defined below
Class Employee
{
public string Name {get; set;}
public uint Id {get; set;}
}
I have a UserControl to edit the Employee information which has EmployeeEditor.xaml and EmployeeEditor.xaml.cs
There are methods in EmployeeEditor class to modify the list of employee
- AddEmployee()
- RemoveEmployee()
- RenameEmployee()
These methods has business logic to update the information in the data object/database.
The life of EmployeeEditor class is till the user control is displayed and it dies on closing it.
I wanted to move above methods outside this class, so that they can be used elsewhere in a functionality such as Undo/Redo which will create/delete an employee using AddEmployee/RemoveEmployee methods.
One solution is to move those methods to a helper which i don't feel to be appropiate as I need to pass all the dependencies of AddEmployee() method as a parameter.
Other solution can be to create a separate class to which will perform all the operations and keep the dependencies.
Please let me know if this problem fits into any design pattern and what could be the better solution?
Thanks in advance!
|
|
|
|
|
Rags1512 wrote: I wanted to move above methods outside this class, so that they can be used elsewhere in a functionality such as Undo/Redo which will create/delete an employee using AddEmployee/RemoveEmployee methods.
There's usually no undo/redo on the database-level. Check out the Memento-pattern, you'll see that it'd be a bit work to implement correctly.
Rags1512 wrote: One solution is to move those methods to a helper which i don't feel to be appropiate as I need to pass all the dependencies of AddEmployee() method as a parameter.
Other solution can be to create a separate class to which will perform all the operations and keep the dependencies.
What dependencies? FWIW, I'd put it in a separate class, which would be embedded in the UserControl. Similar to;
class MyControl: UserControl
{
class MyControlHelper: object
{
}
}
Referring from the UC to the helper-class, is like creating a mini-DAL for your control; all IO is situated in that class. The biggest advantage is that you could write another MyControlHelper-implementation (for say, supporting another database like Oracle or Sqlite) and hook it in there.
Which parameters would you be passing? The way I see it, you'd minimal pass an Employee object. Perhaps a ConnectionString, but that'd be it. If you want to prevent writing a long signature (lot's o' params), then wrap them in their own object (like MyControlHelperAddEmployeeArgs).
Hope this gets you a bit in the right direction 
|
|
|
|
|
|
Is it correct to show the database table in class? I have a class diagram that has objects that save records to a database. So i don't know whether i should show the database table in the class diagram or not. If not allowed then how can I show the relationship between the object and a database? That is how do map objects to a database?
|
|
|
|
|
Qobacha wrote: So i don't know whether i should show the database table in the class diagram or not.
Probably not. Instead you would have a object data model diagram.
However if the project is small enough such that there is only one or two diagrams and only a couple of tables then yes that is ok. However you need to make it clear that that they are data objects rather than class objects.
|
|
|
|
|
You seem to be describing Table Data Gateway pattern (Fowler, Patterns of Enterprise Application Architecture). This class inserts or updates records in a particular table. The convention is to name the class after that table. e.g. The class that updates rows in User table is called UserGateway (or simply User).
Hence, the association between the class (which contains code in C++/C#/Java language to update the table) and the table is described by the name itself. There is no need to explicity show the relationship.
However, there is no restriction to show tables in a class diagram. For example, you may want to describe database schema in UML. All you need is to create a new stereotype, e.g. <>. This stereotyped class can then represent database tables.
|
|
|
|
|
|
Hello everybody,
I'm very new to all this. I'm learning a lot however I feel like there are certain fundamental concepts that I'm not understadning and that is holding me back. Right now, what I really don't understand is how files containing programs and directories on my operating system work.
On my Windows operating system, It seems like whenever I download something new it goes to a file called C:\Program Files. Each file in there will have a lot of little files named bin, lib, include, db, and other things like that. All of THOSE file have files with extensions .dll and .exe. What are these?? Why cant i open them? How do they all work together to produce a single functioning program?
When a computer program is executed how does it know what files to read, where to look for them, what to do with them and so forth?
Can anyone explain this to me?
Thank you very much in advance
|
|
|
|
|
That's rather a long question for a forum like this. Files (which usually have extensions) are held in directories, which may themselves be held in directories. Directories are generally now referred to as folders. Think of it as a set of filing cabinets. Each cabinet has drawers and each drawer has sections, and within each section are individual documents. When you click on a file the shell knows what to do with it by looking up the extension name in a table. So a file with a .exe extension is sent to the program loader and starts running as an independent program. A file with the .doc extension causes the loading of a program that can process it (probably Microsoft Word), and so on.
Take a look at http://windows.microsoft.com/en-GB/windows-vista/Windows-Basics-all-topics[^] for some far better explanations.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
sorry for the length of the question.
that was very helpful, thank you so much!@
|
|
|
|
|
strrom7 wrote: sorry for the length of the question.
What I meant was that it would take quite a few pages to explain it clearly and in full detail. However, I hope the link I provided will help you.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I am a bit confused, that is I want to create an api (for example an api for a charging gateway) using WCF and RESTful api. So what will be the good approach suggest by Microsoft, any fremework?
I would request to you guys please help me on that, any suggestion, article, could be anything is appropriated.
Thanks
Md. Marufuzzaman
I will not say I have failed 1000 times; I will say that I have discovered 1000 ways that can cause failure – Thomas Edison.
|
|
|
|
|
|
Thanks  ? What do you think on the security issues?
Thanks
Md. Marufuzzaman
I will not say I have failed 1000 times; I will say that I have discovered 1000 ways that can cause failure – Thomas Edison.
|
|
|
|
|
Md. Marufuzzaman wrote: Thanks ?
You're welcome? 
Md. Marufuzzaman wrote: What do you think on the security issues?
I think that they are well documented and despite that, still poorly understood. Guess I'm not really understanding the question here.
There's examples on authentication, which is what most customers refer to as security. OTOH, you'd also want to limit the number of consecutive requests, prohibit malformed requests, and log everything that seems "out of the ordinary".
|
|
|
|
|
Thanks for your prompt response, well Do I must use the SSL & data encryption is required?
What is your opinion on that?
Thanks
Md. Marufuzzaman
I will not say I have failed 1000 times; I will say that I have discovered 1000 ways that can cause failure – Thomas Edison.
|
|
|
|
|
Md. Marufuzzaman wrote: Do I must use the SSL & data encryption is required?
For "private" data, always. That might even include a translation-service like Google Translate.
|
|
|
|
|
Thanks, 
Thanks
Md. Marufuzzaman
I will not say I have failed 1000 times; I will say that I have discovered 1000 ways that can cause failure – Thomas Edison.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
