|
Have you? I'm going to try it... so want to hear your assessment
|
|
|
|
|
for the first time, it's kind of cheap, I think
but it's greater quality than my expectation.
Still.. erwin or powerdesigner supports better technology.
but Basic functions are supported in eXERD also.
modified 7-Feb-14 2:47am.
|
|
|
|
|
Technical Details:
.NET Framework 4.0 (C#)
Windows Server 2008
Requirement:
1. Polling a local folder for files
2. Polling a Message Queue for messages
3. Polling a FTP folder for files
4. Polling a SMTP server for mails
We need a single architecture that can be easily extended and also independently maintained for different requirements.
For example if we need to add a new mail server to be monitored, we would just add an entry (with sufficient details) in a config-like file and the system should ideally pick the config entry and start polling for that.
Another example to stop a single polling instance, it should be sufficient to just remove the entry from the config-like file.
Whenever polling succeeds, i.e. if a new mail is received, a new file is found in a folder, etc. the system should be able to instantiate a new controled thread to process the item in question.
It is a complex requirement for me to decide on an architecture solution to this. Would be thankful all who can provide possible solutions along with pros & cons of the same.
Thanks in advance.
|
|
|
|
|
Hi,
I would use something like Strategy[^] to make different polling implementations.
If a strategy finds something, I would let it create a Command[^] that can be executed by a thread. A Command can hold the data and have its own implementation.
All Strategy and Command implementations regarding a technology e.g. mailing could go into its own package/assembly and get wired to a common execution platform at start-up.
I hope it makes sense.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Thanks Keld Ølykke!
I got the overall idea, but I will need to read up on these two patterns and think of the solution (pros & cons). Also the "common execution platform" itself might need a little more thinking ( for amateur like me at least  )
|
|
|
|
|
|
I would suggest building a plug-able framework where the main app's job is maintaining plug-in modules. Each module can be standalone and handle specific source but discoverable by the main app. The main app can scan a folder for DLL or EXE with class that implements some common interface and dynamically instantiate modules using factory. Modules can be add or remove from the folder at will.
|
|
|
|
|
One way to make it generic and easy adaptable is:
Extend the .Net FileWatcher class and create a component that listens to certain file changes in a directory. Next Create a windows Service application that will use this component. The settings and number of instances can be made configurable through the app config file of your windows service application. When a Instance notices a file change write a message to the application log file of the windows event Log.
Using the Windows Event viewer You then can create custom views that filter for your messages generated by your Windows service application. On each custom view you can attach a task that will be triggered each time a message is written.
To this task you can attach a batch file, powershell script or VBScript that will execute and perform your needed functionality each time the task is triggered.
|
|
|
|
|
Hi everyone,
My post will be a bit long but, i think, it is necessary in order to understand the problem. It is not really a problem since i have identified several solutions but i would like to know what are you thinking and if it is feasable.
On one side i have a native C++ framework and on the other side i have a C# framework. Both of them use a modular approach (component based framework).
I have to write some modules that will be compatible with the two framework (C# and native C++).
First solution : i can write my modules for each platform respecting the formalism. But in terms of maintenability it's not perfect since i have duplicate software.
Second solution : i develop my modules for the C# (or C++) platform and use the compiled dll in the second platform.
Third solution (my prefered solution) : I would like to write a common base for the two platform (my modules) and then in order to integrate these modules in both framework i will have two branch. But i think this solution may be technically hard to do but it seems (for me) stylish.
you will understand that the challenge is to take into account the two programming languages : C# and C++
So my questions is really simple :
1) What are you thinking about these solutions ?
2) Is it feasable ?
3) Maybe i forgot some other solutions ?
Thanks for reading these looong post and for your kind response.
S.E
|
|
|
|
|
Managed C++ allows for wrapping native C++ code to the .Net framework, which in turn can be easily consumed by any VB/C#.Net application.
So I'd suggest to write your modules in native C++, then the wrapper in Managed C++.
|
|
|
|
|
Question seems confused.
The concept of "branch" normally applies to source control which is a different subject than creating the code in the first place.
In terms of the code and only the code the following possibilities exist
A. Create two distinct implementations
B. Create an implementation that can be accessed by both and which shares common code in some way.
In terms of library management (based on your use of "branch") you first must decide if the library is in fact a separate deliverable or not. If it is then it has its own source control tree, it own builds and its own deliveries. And the two applications consumes builds that come from that, not code (keep in mind that a 'deliverable' could if fact has some source code or entirely be source code but the concept of 'deliverable' remains.)
If however you want to manage the code as part of the existing applications then the following is true.
1. The two applications ALREADY use a common source control tree. If so you add it an an appropriate spot in the tree. There really isn't any point to do this if you are using A above.
2. The two applications are different source control trees but you are going to MOVE them into one tree. Then the comment for 1 still applies.
3. The two applications are in different source control trees and will remain there. In this case then option B is NOT an ideal solution since it requires code copying.
|
|
|
|
|
Hi jschell, Bernhard
Thanks for your response.
jschell, You're right... The word "branch" is not appropriate here so my explanation is a little bit confused.
I only think in terms of coding. I'm trying to explain what is my purpose.
As these two platforms are component-based platforms (re-usability process), i would like to capitalize the source code.
So, i don't want to create two distinct implementation because of maintainability and/or code evolution.
The second approach i'm thinking of is to implement for one platform (native C++ for example) and then directly use the original DLL on the other plarform (here C# for example). This solution seems to me "hard" in a sense i have to implement some P/invoke process and/or marshalling process (for type variables).
Then, i'm thinking of writing a common base code which will be use on the two platform. For example, i develop my base with native C++ and then write a C++/CLI wrapper that i can use it in the C# implementation.
The simple diagram of this solution would be something like that :
Native C++ impl(common base) ----> C++/CLI wrapper----> C# impl
I think (as Bernhard suggest me) that i'm taking this solution. The idea is if there is evolution of code, i only have to change the common part and the wrapper.
Regards,
S.E
|
|
|
|
|
I already mentioned that you need to determine what your deliverables are first. You haven't discussed that at all.
Your existing applications are either being treated as two deliverables or one. Simple as that.
|
|
|
|
|
Hi,
Sorry for the misunderstanding.
So it will have a common part and as i have to distribute on the two platform there will be two deliverable.
One for each platform respecting the coding convention of both of them.
|
|
|
|
|
nonogus wrote: One for each platform respecting the coding convention of both of them.
So presumably you are saying that your library will be a deliverable.
You can either keep all of the interface code in the library or you could make the one or both deliverables responsible for their own interfaces. Either option has merits. Although I would probably tend to keep the library all in one language and thus one deliverable would be responsible for providing its own interface (and unit testing that.)
|
|
|
|
|
Many thanks for your reply,
you're right and my first idea (still under consideration) is to build a main library in C++ and then providing a wrapper in order to consume my C++ library into my c# platform.
The wrapper will be written in C++/CLI and thus i can simply add a reference in my C# project.
Regards,
|
|
|
|
|
For me it would be Option 3.
I would write the common services as web services and consume them from each application. One code base properly abstracted to provide the functions that you need.
Thanks
JD
http://www.seitmc.com/seitmcWP
|
|
|
|
|
First of all, thanks for all your kind answers.
I would like to describe the solution i chose for my problem. Maybe some other people can read this thread.
So it will be the third option. As you have seen, the challenge is the interop between native C++ and C#.
I have to rewrite fortran code and this rewriting have to be "compatible" with the two framework (C++ and C#).
So i decided to write a core library in native C++ which will be platform independant. Then using a C++/CLI wrapper of my core library to build a dll. And so far i could use this dll in my C# platform as a simple reference in my project.
thanks
|
|
|
|
|
You could write your library completely in C++ and expose public classes as COM. Any language capable of consuming COM can use your library.
|
|
|
|
|
While designing a MTA based system, how should we structure the application deployment such that we can build tenant specific functionality as well and restrict that to the requesting tenant. We need to design asset management so we can build on core and specific components and then load them at runtime based on the tenant who's requesting.
Our environment is web+mobile client with thin server
|
|
|
|
|
There are many great pages available here[^] that should help you get started.
|
|
|
|
|
Are you sure you actually need to keep the assets (storage) separated? Functionality, which you mentioned, isn't really a reason.
Just stating that because MTA is difficult to implement.
|
|
|
|
|
I have used the N-Tier architecture approach where the Business Layer delivers the client specific requirements. You could use the Decorator Pattern to complete.
Thanks
JD
http://www.seitmc.com/seitmcWP
|
|
|
|
|
I have client specific overrides for business rules. We run the industry standard & compliance related rules first and then the client specific rules. We are currently having main biz class having the standard rules and client specific rules as a decorator over that. Then we detect the client id passed and load the appropriate decorator.
Assets are loaded through a CMS due to different branding elements.
|
|
|
|
|
Hello,
I'm wondering about the logic behind Tribalwars, Travian, and similar browser games.
Basically, how to time an action, how to use DB to store those, handle sch a massive number of actions in DB and clients, use service vs a program or the website itself to handle the back-end requests after the time comes, and how actually to realize that the time came.
Note: I'm not asking about the programming language or DB type, Just the logic behind this.
Take this topic as a brainstorm topic to get the best ideas.
Thanks in advance
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
