|
|
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
|
|
|
|
|
Hi Kim,
It is a bit difficult to give you some concrete advice, but here are my thoughts. I think they are classic 3 tier'ish.
The easiest is the lower layer aka the data layer e.g. a simple API that stores data types in a storage (memory, disk, db, whatnot). This can certainly be within its own project (with its own unit tests) - it doesn't need commands or similar. For abstract data classes, etc. I prob. would make a "Core" namespace within this project.
Another easy layer is the top layer aka the UI layer. Whether or not you tie the Application together with the UI layer in 1 assembly/package is a flexibility matter. In any case I would probably make a "Core" namespace within this layer too, but it has nothing to do with the data layer classes - only the UI.
The hardest part is how you design control from the top layer to the data layer and how the top layer is updated indirectly by updates in the data layer. In MVC its the C, in SOA it is the services. I would create a middle layer aka the service layer that knows the data layer, but doesn't know the UI layer. In here you can make a lot of Controllers e.g. Commands that modifies the data layer. If you have a pull design, you can make some poll/query commands too. If you have a push design, you can register a general listener pattern that the UI layer can use, or fire commands going upwards to be consumed by the UI layer (not so popular in these client-server days). This middle layer also will have its own "Core" namespace with abstract Commands and whatnot.
In above way you have a very clean division. It is pretty simple to avoid dependencies from the data layer to others, and it is doable to avoid a dependency from the control layer to the UI layer. One thing to consider is, if the UI layer should have direct access to the data layer. I find this decision hard to make - many cons and pros.
If it makes sense for you to have a common assembly then go make that and let the 3 layers depend on that. Otherwise, just pull in logging, etc. in each layer. A common layer can easily mud your clean dependencies; before you know it there is a utility class that knows how to calculate some business data and it is used by both the UI and the Data layer.
I hope it makes sense and triggered some thoughts.
Kind Regards,
Keld Ølykke
|
|
|
|
|
I'm not a project manager, i'm just a developper. But i wanna know yours opinion for coding together in a team. Here will listes my coding habits which i think is good. This article is partially on the opposite of another article of mine "Several Easy WPF Teamwork Tricks"
Unify naming convention. We'll encounter some Here is a paragraphe of the reply of a friendly member of CodeProject :
While some people may not like switching coding styles, it does not take very long to get used to coding a different way. There is a huge benefit to having a standard coding style. On my development team, we adhere to a somewhat strict coding style. It doesn't matter what file you look at, it is written the same as every other one. It is very easy to read other peoples code since it looks like your own. I know immediately when I look at an identifier whether it is a member field, public property, or local variable without having to go search for where it is defined. If I did have to search for where it is, it would be in the same spot in the file as it is in every other file because there is a standard.
Unify comment humain language. I'm a Asian guy who lives in France. My main language is not french nor english. But i read only English technical books and i speak French everyday. It's sure that i don't write Chinese in my project because all my other collegues won't understand it. But should we comment with English ? Or French (Native humain language) ? One point i'm sure is that comment with both English and French could be a very terrible thing. (At least, it makes me very angry sometimes).
Version control of third party libaries. I use DevExpress, mysql and so on in my project. I'd like to update them once they published their new version. It cause sometimes a very big change in my project. But i'd prefer to update it all the time. Because we can track its changes without missing some important things. But if work with team? I think we should negociate it. I prefered to suggest them to update versions frequently. Because we can always keep the same version for the same project. I know it cause us lot of work in every update.
Length of Method. I don't like methods which contains more than 30 lines. It makes code urgly. It's my style. Because i found that it's more clear when we read method with less than 30 lines. We could find the function module quickly. We watch a function module with F12 instead of scroll our mouse. Method's name could also be used as a comment. It sometimes forced us to write more reusable methods.
public void RunSome()
{
try
{
if (!PrepareEngin()) throw new Exception("No usable engin");
if (DoWeHaveAnCat())
{
PlayWithCat();
}
else if (GoToBuyAnCat())
{
RunSome();
}
}
catch (Exception exp)
{
throw exp;
}
}
private bool PrepareEngin()
{
return true;
}
private bool DoWeHaveAnCat()
{
return true;
}
private void PlayWithCat()
{
}
private bool GoToBuyAnCat()
{
return true;
}
Don't have too many empty line in a method. It wastes my time to read it and positionning!
A teamwork should be harder than a solo work. I'll work with a team in 2014. I'm not project manager, but i wish we'll have a good 2014
History
An opposite article of mine ("Several Easy WPF Teamwork Tricks") was criticized by members. I'accept that it wasn't a good article. But it's also an other way of thinking.
modified 7-Jan-14 2:21am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
