|
it would be a discussion for as i read your comments i might have additional questions about this topic. also it does not have to be on run time perse at the moment i have multiple projects (and they are ready for deployment) having the UI that i need to load depending on a user role. my ultimate goal would be to place all of those little projects i made to a single app and load the needed UI after the user with a specified role log in.
|
|
|
|
|
PhyxeTernida wrote: my ultimate goal would be to place all of those little projects i made to a single app and load the needed UI after the user with a specified role log in.
So what is your actual question?
|
|
|
|
|
im very sorry if om not that clear, my question would be: How am I going to accomplish that? Also I wanna know how the process work and if its possible with C# VS2012, so I am also asking for sample projects and references where I can learn as much as I can on doing such thing.
|
|
|
|
|
PhyxeTernida wrote: How am I going to accomplish that?
By designing and writing some code.
PhyxeTernida wrote: I wanna know how the process work
Not sure what process you are referring to.
PhyxeTernida wrote: if its possible with C#
Most likely yes.
If you are looking for sample projects then you should go to the Articles section[^] and search there. When you have a specific question then come back here and people will try to help you.
|
|
|
|
|
PhyxeTernida wrote: so I am also asking for sample projects and references where I can learn as much as I can on doing such thing.
You'd be asking other things, like "how do I check whether someone is in a specific role".
Start with small things. There won't be a forumpost explaining how to do a complete project.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
You may get more/better responses to this question, here, if you include the complete text of your message on QA, and indicate which technology stack in .NET you are planning to use to implement this: WinForms ? WPF ? ASP.NET ?
Also, I suggest you take a look at Managed Extensibility Framework (MEF) [^] which is a relatively new facility from Microsoft specifically for managing/implementing plug-ins, etc.
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
Why does it need to be a plug in at all. You have to build the specific UIs so put them all in the same app and after login where you will get the role of the user you decide which UI to display.
We have a similar environment except a user may have multiple roles and functions within that role across multiple applications, web, desktop and mobile platforms. We cannot use AD groups as the response time (from the AD team) is abysmally slow.
We have built a single logon application that picks up the users credentials and passes the object to the client application on start up. Each application may have multiple roles dictating different views, this is built by the individual developer using the details from the credential object.
User credentials are maintained in another app by OUR user team, when you have 20+ applications and 1000s of users it gets a little unwieldy  .
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Now that we know this will be a Windows Forms based project: some specific ideas based on WinForms' facilities:
Assumptions:
1. you will use standard system-services to handle the security aspects of verification of log-in of users, meaning: you will use Windows' Groups/Roles/Permissions facilities and encrypted log-in information stored in your database.
Ideas:
1. Log-in Application: one Windows Form, UserName, Password, Text Fields, LogIn Button, Exit Button.
a. stand-alone project, contains no other Form definitions, no hard-coded filepaths to the location of the users' interfaces ... Forms (Admin, Manager, User ... etc.).
2. UserFormLocator Service: receives a request from the Log-in app for a path to a valid folder containing the .dll with the user-interface appropriate to the logged-in User, and returns the filePath to the LogIn app after a valid log-on.
3. Forms for different types of Users ... for example, Admin, Manager, User1 ... these can, of course, all use a common base host interface. For example, you could have one main Form with certain common features defined in a .dll, then have a separate .dll containing a Panel with all the specific Controls for each type of user. At run-time the common Form can be loaded, and then the specific Panel loaded and inserted into the common Form's Controls collection.
4. After a valid log-in, the Log-in Application uses the filepath to the .dll returned by the Service to Load and instantiate the particular user interface for a given type of User. The Log-In Application closes its own UI and transfers the message loop to the newly instantiated user-interface (Form).
Technical Note on 4.:
This requires use of an explicit ApplicationContext in WinForms: rather than starting the Application with the usual command to "Run" a Form, the Application is started by launching the instance of an ApplicationContext: this allows one to close any given Form and open any other Form. This also requires some caution since the Application can still be running with no open Forms: typically the need to close a WinForms app launched in this way is dealt with by over-loading the Closing EventHandler of all Forms and shutting down the Application when the last open form is closing.
Conclusion:
I've omitted code here, and other technical details, including the probable need for the Log-In Application and the dynamically loaded user-interfaces to share Interfaces. If there are further detailed questions on what's described here, I will respond with code, as appropriate.
The key idea is that the Log-In application be as "divorced" from the final interfaces loaded for different types of Users as possible for (what I hope are obvious) security reasons.
I have implemented each step described above to the "proof of concept" level.
«I'm asked why doesn't C# implement feature X all the time. The answer's always the same: because no one ever designed, specified, implemented, tested, documented, shipped that feature. All six of those things are necessary to make a feature happen. They all cost huge amounts of time, effort and money.» Eric Lippert, Microsoft, 2009
|
|
|
|
|
|
I'm putting together what is essentially a template for listeners for a Message Queue server. The process I would like to have is the following
1) Connect to correct Message Queue
2) Listen for Message
3) Retrieve Message when it arrives
4) Process the message
5) Return results to the return queue
The way I would like to build the template is that all the steps but step 4 are handled by the template. Ideally I could then write individual libraries that could be plugged in to handle the processing of different types of messages to build out the individual listeners. I could script the builds for the all the listeners so if a change was made to the template I could run the script and rebuild all listeners at once or if there is a change to a individual listener I could just rebuild that listener.
Basic OOP seems to have fled my brain this today and I cannot think of how to do this. I'm thinking that I will need to use reflection to load the different dlls at runtime and then separate the listener executibles into their own directories so they can be placed with the correct library. Does this sound right? It seems that there should be an easier way but it escapes me at the moment.
Thanks for any help you can give.
The hurrier I go the behinder I get....
|
|
|
|
|
I'd suggest looking at Microsoft Extensibility Framework[^] instead of rolling your own using Reflection...
A positive attitude may not solve every problem, but it will annoy enough people to be worth the effort.
|
|
|
|
|
Hi,
In his recent blog[^] Uncle Bob come up with a situation that explains interface is harmful. Here is the code snippet taken from his blog.
public class Subject {
private List<Observer> observers = new ArrayList<>();
private void register(Observer o) {
observers.add(o);
}
private void notify() {
for (Observer o : observers)
o.update();
}
}
public class MyWidget {...}
public class MyObservableWidget extends MyWidget, Subject {
...
}
Here he explains that to implement Observer pattern done correctly, compilers must allow multiple inheritance.
So my question is why don't the MyObservableWidget implement using dependency injection like below to avoid multiple inheritance with greater degree of separation of concerns?
public class MyObservableWidget extends MyWidget {
private Subject subject;
public MyObservableWidget(Subject subject) {
this.subject = subject;
}
}
Of course the Subject class should be an abstract class. Please let me know your thoughts.
Thanks,
Pop
|
|
|
|
|
"Ivory tower theorizing considered harmful." -- DMR
|
|
|
|
|
|
I gather that this article needed the help of a proctologist with a torch.
|
|
|
|
|
Pete O'Hanlon wrote: with a torch
Or maybe just an ear-trumpet? 
|
|
|
|
|
Was that a brainless question? 
|
|
|
|
|
Not completely, but it's more a Lounge type discussion, than a technical question.
|
|
|
|
|
Oh that explains the hatred towards my question. But I was not trying to degrade that article. All I meant about the technical aspects of that idea. Sorry for my ignorance; I thought my solution can overcome the problem specified in the article.
Thanks,
Pop
|
|
|
|
|
I think the "hatred" was directed at Uncle Bob, not at you.
|
|
|
|
|
Thank you! 
|
|
|
|
|
Was there hatred towards your article? I was actually commenting that o' Uncle Bob seemed to have pulled his argument out of his posterior.
|
|
|
|
|
|
Hi,
Thank you for the blog link.
You propose what is called mixin, which is really the go to solution to avoid bloated inheritance hierarchies.
The good thing about mixin of Subject is that you hide functionality and avoids to duplicate the code in Subject.
The bad thing is that you still need to duplicate the code that calls Subject aka relaying.
DI with mixin is also good since you make the dependency known to the outside. This opens up for implementation replacement from the outside and gives better transparency.
However, Uncle Bob really wants to hide stuff and use inheritance to avoid ANY code duplication and he can't do that in a single inheritance language.
I love interfaces because they form a specification layer without any implementation details. I love abstract classes because they can be implementation templates for concrete classes. I do not want to mix the 2 concerns - at all. And it IS a tad annoying when you need add mixin in you abstract classes to avoid code duplication.
I wouldn't mind multiple inheritance, if the language/compiler could manage diamonds in a consistent and obvious way (No, C++ doesn't). The class hierarchy is however implementation - not specification (IMHO). Uncle Bob doesn't address that view on the interface keyword.... and I am not sure the interface keyword had that view in mind when invented.
|
|
|
|
|
Keld Ølykke wrote: No, C++ doesn't
I think it does. Why do you say it doesn't?
Keld Ølykke wrote: class hierarchy is however implementation - not specification
Agreed. Hence, I don't think interfaces are "harmful", but what Uncle Bob was really complaining about is not being able to have multiple base classes.
However, I think true separation of concerns would use neither DI nor inheritance to do his observer pattern but rather a separate "observer manager" class that does both the observing and registration/deregistration.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
