|
OK!
// Registration phase
1. Manager creates a container and registers modules.
2. Manager passes a child container to every module to registers it's services.
3. Module1 register LegitLogger as ILogger.
// Resolution
4. Manager passes root container to every module to able to find services added by other modules (on child containers).
Without IServiceLocator wrap, Module2 can register DummyLogger as ILoger on the root container so that LegitLogger will never be found (child containers will not be searched).
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
|
|
|
|
|
I'm a touch confused as to why you think you need to pass the child container in. Remember that unity looks for modules that implement IModule - so, create a base module class that takes the parent container and creates a child container internally. Something like this:
public abstract class ModuleBase : IModule
{
public IUnityContainer ParentContainer { get; private set; }
public ModuleBase(IUnityContainer container)
{
ParentContainer = container;
Container = container.CreateChildContainer();
}
}With that, you have a segregated module architecture that will allow you to set up the interfaces how you like. I would tend to create a fluent architecture here to simplify the registration in here, but that's just me.
This space for rent
|
|
|
|
|
In that setup the following code is possible:
public class DefectiveModuel : IModule
{
public DefectiveModuel(IUnityContainer container)
{
}
}
The setup I'm going for is more like:
public interface IModule
{
void RegisterServices(IUnityContainer container);
void Init(IUnityContainer container);
}
public class Manager
{
public void Init(IUnityContainer root)
{
Modules.Foreach(m => m.RegisterServices(root.CreateChildContainer()));
Modules.Foreach(m => m.Init(root.Wrap()));
}
}
So modules will only be able to configure there child container.
However, they will be able to use the root container to access services added by other modules on child containers under root.
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
modified 15-Feb-17 10:50am.
|
|
|
|
|
Unfortunately, because the parent container is still available to you, there's nothing stopping the inner services from trashing the root container - all they need to do is get the Parent from your IUnityContainer; you're not going to be able to prevent that.
This space for rent
|
|
|
|
|
 Just noticed.
Edit: However, It's still hard to predict the order in which the modules will be called.
Edit2: If there was an IServiceRegister interface. Then we could use it to wrap the container during registration.
"The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke
-- modified 15-Feb-17 12:07pm.
|
|
|
|
|
I have handled this, in the past, by hiding the module registration. This works by putting a proxy registrar in place and then exposing this through the module registration instead. At some point, I'll put out an article describing how I did this (part of the idea behind this is that this approach makes it easier to swap IoC containers around).
This space for rent
|
|
|
|
|
 Good idea.
PS: I just thought of the idea of having to replace all those IUnityContainer references. That is one scary thought.
____________________________________________________________________________________________________
"The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke
|
|
|
|
|
As for what I'm trying to solve.
In the current setup a module can only use it's services and the services registered on the root container, So modules cannot share there services.
We could pass the root container to modules so they can register there services in a single pool, but then a module can intercept another module's services.
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
|
|
|
|
|
aboubkr90 wrote: The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
Please do not apply that philosophy to daily traffic.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Good thing i don't have a license. 
____________________________________________________________________________________________________
"The only way of discovering the limits of the possible is to venture a little way past them into the impossible" Arthur C. Clarke
|
|
|
|
|
Hi,
Im working on an old 9-10 year product that was written using Visual Studio 2005, dot net 2.0. I have upgraded the SQL backend database to 2012. This is a ASP.NET Web Site project. It also comes with its own MSI installer and some Windows Forms Utilities. The ASP.NET pages are looking very old, there are roughly 60-80 or so pages. It currenlty allows certain menu's / pages to be visable via XML configuration. I want to improve the look and feel dramatically. Since VS2005 is no longer supported and will not install on Win10 I have started to migrate to VS2015. The old asp.net pages use aso:Table, asp:TableRow, asp.TableCell but I want to migrate to some type of template engine. My own research suggest moving product to asp.net MVC, this will probably require a rewrite. Does anyone have any suggestions where to go with this task. Many thanks..
|
|
|
|
|
You essentially have two options:
1) Evolve
- Open the solution in VS2015 to upgrade the file format;
- Optionally upgrade the project to the latest version of .NET, and deal with any breaking changes[^] that apply;
- Optionally convert the "web site" project to a "web application" project[^];
- Start making incremental changes to the layout and styles;
2) Rewrite
- Rewrite the entire project in ASP.NET MVC or ASP.NET Core
- Choose between ASP.NET and ASP.NET Core | Microsoft Docs[^]
If you're just looking to make a few changes to the styles, option 1 is probably the way to go. WebForms isn't going to stop working any time soon. And it's possible to add MVC and WebAPI features to an existing WebForms project, so you could rewrite the site one part at a time if necessary.
But if you want to completely rewrite the site, MVC or Core is the way to go. Just be aware that it could be a very big job. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
We all know programming is problem solving, and often the ability to problem solve effectively is one of the most desired traits in a professional programmer. However, compared with syntax books and tutorials, there are surprisingly few articles on steps used to problem-solve any programming-related task.
Give us a list of general steps that work for you to solve programming problems. Here is mine. Feel free to critique it as well:
1. Determine the problem.
2. Break the problem down into smaller problems
3. Prioritize the smaller problems
5. Think of solutions for the first problem on the list and begin working
7. Review code and make it better
I often hear in interviews that people are "Trying to see how the candidate solves/approaches problems," so clearly this is a big one. Also, please note that the scope of this post is specifically smaller problems such as basic algorithms used in programming tests. Not talking about system architecture here. Any tips appreciated.
|
|
|
|
|
To Solve any problem whether smaller or bigger a Programmer should follow The software development life cycle (SDLC) ,Software Development Process.
Which includes many steps like:
Review the problem(Reproduce the problem),
then Investigate the reason behind it,
design how to solve the problem ,
check effected areas,
codding ,
Testing
|
|
|
|
|
TheOnlyRealTodd wrote: there are surprisingly few articles on steps used to problem-solve any programming-related task
..because it would be the same abstraction as you described. It is also not limited to programming, it is a basic pattern that most people follow.
Diagnose
Prioritize
Plan
Implement
Review
Outside of that, the only other approach you could try is using gasoline, a lighter, and threathening the problem.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Without any "artifacts" (i.e. deliverables), the "process" is useless; i.e.
1) Scope (Context diagram)
2) Problem Definition (doc)
3) Preliminary analysis (level 0 DFD; UML; whatever)
4) - Current physical
5) - Current logical
6) Design
7) - New logical
8) - New physical
etc.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
So I pretty much exclusively write windows drivers, kernel mode, and its a very demanding environment. Lost of issues with concurrency, and something you user mode guys wont have come across, priority. Your code can be called at PASSIVE_LEVEL, DISPATCH_LEVEL, or, if you have an interrupt, some kind of DIRQL.
Now when you are at elevated levels, you cant touch pageable code or data, it has to be non paged, else you risk a page fault crash. You also cant wait or sleep, or allocate non paged memory at elevated levels.
So something I use, architecturally a lot, is a function call queue, and a thread, which runs at PASSIVE_LEVEL (thats real time priority by the way) to empty the queue.
Because only one function at a time is run by the thread, when taken off the queue, data cant be touched at the same time, and because the thread runs at passive level it can wait, and can call any function, or use any data.
And its very easy to use. Any event that occurs, just save the relevant data in a context, and queue it.
The whole functioning of the driver becomes very relaxed. Almost nothing needs locking, and almost all code runs at a low priority. Its a very good solution to highly complex environments and makes for aq very good product.
|
|
|
|
|
We're lucky to have a kernel mode guy like you frequent the site. Your expertise is invaluable because driver development to most of us user mode guys is a black art.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thankyou for the worship, contributions will be gratefully accepted.
No, but seriously, implementing your own function queueing this way ios such a great solution to complex, event driven implementations that it ought to be taught in school. It has literally saved me many times. It is SO disjointed, so flexible.
One beauty is that a function, that expects a certain state, when run, and if that state is not there yet, can requeue itself, and because this is at low priority takes no CPU time. It is a beautiful engineering solution. You never get a deadlock situation. It can reduce any complex environment to simplicity. Seriously, I love it.
|
|
|
|
|
Munchies_Matt wrote: ios such a great solution
I didn't know you were an Apple Fanboi.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
FlagComposer: let's build a software tool using XML to define a set of national flags.
This project is mainly addressed to students or programmers who'd like to have a challenging programming task to solve as an exercise in their free time…
So, here is the description…
Let's imagine, we want a software tool to define a set of national flags. The tool should use XML data to (1) draw a GUI and (2) to generate an output.
Aim of this application is to build a GUI starting from a XML file (e.g., see "FlagComposer.xml" in the GitHub linked at the end of the post) and to generate an output XML file (e.g. "FlagGermany.xml") according to what has been set by the user in the GUI.
In input we have one (or more… but not simultaneously processable) XML file(s) defining which elements (graphical controls) should compose the GUI, which parameters are needed to define a flag, which values are valid; in output we want to have one XML file for each flag definition. It is not required to display an image of the flag: the XML file is all that we want to have as a result of the processing.
The application must read a XML file containing a "GUIDefinition" element and draw a graphical user interface accordingly. It must also be able to generate and write out a XML file containing a "FlagDefinition" element.
[Application is launched]
==>
[Read XML <guidefinition>]
==>
[Draw GUI accordingly]
==>
[Process user's "Save" or "Exit" command]
==>
["Save" creates XML <flagdefinition>]
==>
[Exit]
Starting from the <guidefinition> element of the input XML data, we want to build up a GUI where the user can enter the required parameters, for instance (…see "FlagComposer.xml"):
1. a "Name" should be entered through an editable text field;
2. a "Direction of Stripes" specification should be entered through a list box (or choice box) displaying the available options ("Horizontal" and "Vertical") and allowing the user to select one of them;
3. a "Number of Stripes" should be entered through a numeric spin box ranging from "MinValue" to "MaxValue" (eventually initialized to a "DefaultValue");
4. a set of list/choice boxes should allow the user to enter the colors of the flag: the GUI must provide N occurrences of the "Color of Stripe" parameter (list/choice boxes) according to the previously set "Number of Stripes".
Once the user has entered all the required data, an enabled button or menu option should allow him to generate and save the output XML file with the final <flagdefinition> element (to have an example of the output file, see "FlagGermany.xml").
To develop the application, free or open source tools should be preferred over commercial ones, but the choice of the programming language, IDE and framework, with which to implement the application, is ultimately left open to any option and demanded to the programmer (that is, to anyone who's going to try to implement a solution to this problem): you may choose whatever language or framework you like. Of course, the simpler and faster-to-implement-and-maintain the solution is, the more it will turn out valuable.
A set of XML files, to use as a model of the input data (<guidefinition>) that should be used by the application and of the output (<flagdefinition>) that should be produced, is available on GitHub (there you'll find XML data files only; there's no source code, as the application doesn't exist yet…):
https://github.com/FromTimeToTime/FlagComposer/
Please, fork the GitHub project to suggest your ideas or your implementation of a solution…
As you can see, the application that I'm asking you to design (and eventually develop) is just a "toy", but it could give me the crucial hint necessary to deliver a solution in the professional field where I'm working… and - yes - to save my job!
(In the company where I'm currently employed I'm struggling to solve a problem with several technical analogies already since a long time, unfortunately without success till now… Well, I'm just a junior developer, after all; I hope you'll understand…)
XML is a ground requirement in this "FlagComposer" simply because it is a requirement (for the communication between many software components, having distinct producers even) in the project I'm professionally working on. For understandable reasons, I couldn't post anything related to the real project… but in the "FlagComposer" problem (note again that there's no such application yet!) a few technical aspects of the "real" project, whereto I have to deliver a solution, are reflected.
Also links to useful resources and to existing source code doing more or less what is involved here could be very helpful!
Any contribution will be very appreciated! Thanks a lot in advance!!!
|
|
|
|
|
So what's the question?
You read some xml, and use it to create a flag; consisting of "shapes" and "colors".
But you haven't accounted for some of the more "graphic" flags.
Holland and France flags are easy; not so much coming up with a "snake" or an "eagle" (Mexico).
You now have to define (graphics) "paths"; or you're back to using images.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
The application that I'm asking you to design (and eventually develop) is just a "toy", intended to explore the possible solutions to a problem with the described technical requirements (in short: XML input to generate a GUI; XML output to return an answer to the user): I'm not aiming at representing faithfully all the graphical characteristics of the flags of the countries of the world; painting the flag graphically is not required and doesn't interest me at all, indeed. Unfortunately, I couldn't think of a better sample project to explore the issues that I'm facing with the industrial software I'm currently dealing with…
|
|
|
|
|
yobibytes wrote: The application that I'm asking you to design (and eventually develop)
Sorry, but this site does not provide code to order. If you want this tool then you need to do the work to create it.
|
|
|
|
|
yobibytes wrote: The application that I'm asking you to design (and eventually develop) is just a "toy"
So, you said in your original message that you want us to do this to save your job. Unfortunately, that's not the way we work here - if you want code to order, try RentACoder (or whatever it's called nowadays). You have to understand that we are all volunteers and the vast majority of us code professionally, so we don't have the time or inclination to write this for you.
It sounds as though you're trying to create a "XAML" style of application - search for Marc Clifton's excellent MyXaml series of articles. These should help you.
This space for rent
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
