|
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
|
|
|
|
|
Have a look here[^]
Veni, vidi, caecus | Everything summarizes to Assembly code
|
|
|
|
|
The question isn't clear.
The games are just applications just like any other application. There are specific technologies and methodologies used to achieve that.
And doing it requires that one learn about those. Doing it well requires that one learn about other technologies as well so that one can choose the best ones to implement it.
In general the term used to describe what the above encompasses would be referred to as the "architecture".
Member 10508854 wrote: Take this topic as a brainstorm topic to get the best ideas.
Large games will not work unless one knows quite a bit. So the best idea would be to start learning the basics of some technologies including databases, web server architectures and perhaps browser based user interfaces.
|
|
|
|
|
Hi all!
I'm working on a UML / ER modeling tool, and I need some opinions.
My C# solution currently has the following projects/assemblies:
Core - defines basic stuff like logging, a hierarchy of elements (and operations on that hierarchy), what a model is, and that a model may contain model elements
Content - defines subclasses of model element, ie concrete stuff that a model may contain, like Class, Attribute, Table, Column, and how these elements relate to each other
Engine - defines operations on the content, for example building a model from an external file, conversion from conceptual model (classes) to ER-model (tables)
ViewModel - an MVVM implementation
Application - A WPF UI.
Random comments:
- Most classes in Core, Content and Engine are public, because ViewModel needs direct access to them.
- I want to somehow define Services provided by Engine. ViewModel will call these services.
- This will be a desktop solution, but I might want to make it browser-based later. Would it in that case make sense to implement the "services" using MCF, which I'm new to?
- I am currently not using interfaces (as in public interface IMyInterface {}) for the purpose of handling dependencies between assemblies.
So my "problem", then. Content references Core. Engine references Core and Content. ViewModel references Engine, Core and Content. This just doesn't seem like a working separation. I'm just now starting on the Application level, and I notice it will definitely reference ViewModel, but that I also potentially need to introduce elements to both Engine and ViewModel that should be available to ViewModel and Application (Commands and services). So I feel I need to redesign a bit. The question is whether to split more (create CommonXXX -assemblies containing, for example, interface declarations used by other assemblies) or to combine assemblies. I think combining in this case makes more sense, although I generally like to split things.
Engine operates directly on Core and Content objects, so it might make sense to combine these three into the same assembly, as they are really quite tightly integrated. In that case I could make all classes non-public, and publish them for ViewModel to use through interfaces. Then the question is whether these interfaces should be declared in a Common assembly or in the same assembly as where the implementing classes reside.
An attractive alternative to publishing the data objects using interfaces: I thought I might allow selective access to data objects and services through scripting, in which case I could have wrapper "API" objects (think Engine returns new ClassAPI(aClass)). These would be declared in the current Engine assembly, and the view model objects could then use those instead of the actual data objects defined in the Content assembly. Then I could implement a scripting language which could use reflection to access all the API objects' methods and properties. Using these API objects, I could easily publish, for both scripting and UI, any aspects of the core data classes (and "services" as methods) I want/need, and I would not need any separate interfaces, and there would be no need for currently public Core/Content/Engine classes to be public.
So, after a possible merge I would then have:
Core - Defining both data model and services, contains old Core, Content as well as Engine. Either the "API layer" or some sort of service implementation, or a combination of these, would be the only public view into this assembly.
Common - Stuff like Logging and genuinely commonly used items, possibly including interface declarations
ViewModel - Uses Core's API or service layer, and some Common elements
Application - the WPF UI
Sounds better, or does it?
If this admittedly superficial description evokes any kind of reactions, I'd really like to hear them 
Cheers,
Kim
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
