Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
For my company, I have developed one winform application, that handles Unified COmmunication.
It's been 1 year in development. I Just write global functions in seperate classes, and write the code in either form or class. Now They wanted me to make three seperate copies(UI of each changed) of the same Software. I have changed all UI and everything needed, and made 3 copies. But now, I feel it very difficult to correct any issues, or add any features. I have to change it in my all three copies. How can I solve this. Thanks.
I'll assume the three versions are very similar. First off, it's of the utmost importance that you keep your project under source control.
Personally, I would have created a dev branch for the main version, and then create two other branches for the 2 other versions (e.g., dev-v1 and dev-v2), created off the main branch.
Then, whenever I had to apply a patch to all 3 versions, I'd do it on the dev branch, and then merge dev with dev-v1 and again with dev-v2.
So far I only addressed the source control issue, but as CSharpie pointed out in the comments, you should definitely separate the presentation layer (i.e., forms) from the business logic. Furthermore, these two should also be separated from the data layer.
Take a look at Multitier architecture.
Separation doesn't necessarily mean different projects or solutions. Having a logical separation (e.g., having sets of classes with very well defined purposes, following the SOLID principles etc.) is often enough. In your case, however, it seems that the presentation layer should be in a different project than the other two.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Some 30 years ago, I developed a big app for fresh fruit packers. I followed a nice paradigm, taken from Informix-4GL: the same screen allows the user to set a "query by example" or to insert a new "record", or update one of them after a successfully one. It maintained a "current list" (the resulting query result and the new records added) wich could be navegated with PgUp and PgDwn Keys. Of course, all that stuff was expressed as mapped text.
The very important thing is that the screen was idle until the user did a "command" to start a new query, an insert or update (or even a delete) operation.
Now, it's the time to evolve that app.
I'm thinking in Wpf and its Preview* group of routed events, to catch the main user "command".
But because there are lots of screens (near one for every entity in the database) it's important to set what is common between them.
Is it the best way (in Wpf) to set one or two "super classes" of Windows for this approach?
TIA
Technically — sure, you can create a class that inherits from System.Windows.Window, have all windows in your app inherit from that one, and implement some common logic in that class.
However, this approach is not considered a best practice for WPF and other XAML-based platforms. Your window and other GUI classes should only contain code specific to presentation. Your model classes that handle the DB queries should not depend on the exact GUI you’re using to present these models.
While not required, a third-party MVVM library is helpful to e.g. provide design-time models for the IDE. As for the specific library, lately I prefer Caliburn Micro, before that I had positive experience with MVVM Light.
With MVVM, it’s fine to have a base model class with some logic that’s common across different model classes. In fact, many libraries encourage you to do so. They provide their own base classes for your models. Such as Screen or PropertyChangedBase from Caliburn Micro.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
The project I am working on will have to be migrated from C# to F# based on what brings food on the table tomorrow - in other words, the two languages have to live side by side in this project for years to come.
The problem I am faced with repeatedly is how I should organize projects in the solution to meet this need.
I translate pieces from C# to F# all the time, because it frequently shortens the development time and increases the quality. But I end up with C# code that wants to use F# code, and F# code that want to use C# code, in the same layer, or at boundaries between layers or modules. I find myself putting code in the wrong projects just to avoid creating yet another project in some layer.
The situation is not bad now, but I worry that I will paint myself into a corner at some point, unless I can come up with a pattern or a structure, or simply understand the problem better.
Is there some modification to a normal F# architecture - a pattern, a substructure or a superstructure - that is well suited to such a mixed solution?
Are there patterns that are known to be especially helpful in solving this particular challenge?
Use an interface to communicate between the two languages.
Typically when porting, f# is the lower-level dll and C# can call f# as usual.
Now for f# to call c# define an interface in the f# dll (e.g. IClibApi) that is implemented in c# (e.g. ConcreteClibApi extends IClibApi). Create an instance of ConcreteClibApi and pass it to f#. Now f# can call c# thru IClibApi.
Later you can start porting ConcreteClibApi :)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I find the way of "having controller/view in same project, all model in separate class library" not intuitive to me. I prefer to have it vertically, i.e. having related controllers/views/view model in separate projects.
So I look up the internet and find that some (not many) people are using the area feature, but I find it a pain when it comes to do routing.
So why can't I put controller/views/view models as separate projects instead of area? Am I not able to do that or does that decrease performance so nobody uses it?
You can structure the solution however you want. Everything is configurable to work the way you want. Furthermore, the way you structure your solution should have no effect on performance.
It's going to be much more straightforward to structure the solution the idiomatic, default way. Other users of MVC are already familiar with the default way, which makes for easy collaboration. Even if you feel another structure is better - even if it is better - you're still going to greatly benefit from tolerating the default structure.
You actually can move the views model and controllers to the other projects.
It is not something available out of the box.
You would need to create your own implementation of few MVC infrastructure classes like: ViewEngine, controller factory and etc. I wouldn't recommend going this way as you would have really hard time migrating your project to new versions of ASP.NET MVC and the classes which Microsoft supplies are well tested and optimized.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have three projects(C# libraries) namely A,B,C.
All the 3 have 3-4 xml files(in general can be resources) associated with them.
Each of these projects have classes that access these files for settings and information.
(loading xmls when ever they need)
The problems is sometimes there is a need that a class in project C may need to access
resources(xml files,images etc) of project B and vice versa.
Also these files may or may not be a part of the project solution.These resource paths
can come from app.config etc.
Its really becoming tedious to work out how to centralise access to these resources so that
all three projects can access them uniformly.
Currently all the projects load the files using app.config.
Also i'm trying to minimise the number of times a xml is loaded.(ideally once).
But given the projects are different i have to load it again.
I thought of using a Singleton class as it would make more sense for making uniform access but haven't quiet figured out a way.
Anyone has come across similar situations?
Are there any design patterns or best practices for sharing resources across projects?
Create one library containing the class(es) that access your centralized XML settings, and reference that library from the other libraries.
You don't necessarily need a Singleton for this, but putting it in one place will allow you to focus your efforts on things to improve it later, possibly caching, etc.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am still visiting school and will finish my exams next year. Since two years I am working as (the only :-( ) in-house dev for a company providing financial services to Laboratories and doctors. After spending the first year fixing their existing Application and realizing, communicating and agreeing that it won't meet future requirements i rewrote it from scratch. This is my first LOB application.
I needed a "IEnumerable.ToDataTable()" method to do simplify certain things in the Application. I realized that existing solutions wouldn't meet my performance and flexibility requirements, so i came up with a solution based on Dynamically injected IL code myself.
I thought that this might be a good way to contribute to the community, thats why i asked my employer if i may take some of those code and release it under LGPL. They agreed and that's where my first project is:
ModelShredder
Since this is my first OSS project and i am relatively unexperienced with running an OSS project on my own I am asking you for some "best-pratices" and what i can improve on it.
First read this book:
You can download it free of charge here: http://producingoss.com/ There are also some nice screencasts there that may be some use too.
It covers everything you need to know about looking for, contributing to, starting and maintaining an open source project,
It all depends on if you're going to have a team help you or not. It'll be simpler to start doing it yourself if you have the time if for no other reason than you can work out how you want to proceed without worrying about politics.
For a start, any code used as a framework or a library typically needs to be developed to a much higher standard than what you might write for an internal application. This means you need:
Sufficient user and developer docuemtnation;
Unit tests with decent coverage;
A license;
Tagged versions in source control; and
Released binaries and source code with checksums.
Additionally you'll need a method of:
Communicating your project status (release notes, goals, etc); and
A means to allow people to raise and track issues.
Google Code (as just one example) can do pretty much all of this for you.
I would also suggest you register the domain name for your project (typically projectname.org for open source). If the one you want is taken already, you may want to change the project name, particularly as there might be cause for confusion.
The google code pages look pretty good to me. You might want to think about adding a support group on Google Groups.