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 1 year ago.
Improve this question
I wanted to know if there is a site that references "conventional" folder/file names. For example, one that explains what a "Models" folder should contain, what a "Helpers" folder should contain, etc.
I'm starting to develop projects with a lot of content, so it's important for me to start now to get the right habits to organize my work.
Thanks in advance for your help.
EDIT: To be more precise I would like to know the role of each folder/file according to their names because I see a lot of projects with Models, Helpers, etc folders and I don't really understand the difference between them.
My question is about console applications in .Net 6
A Models folder would probably contain classes like Person, Customer, Employee etc, most of the times models that are have their own data tables. A Helpers folder classes that maybe don't have a lot of logic, if that's the right word, for example an EnumeHelper class that return the description of an enum. If you want to see more about how to structure a project: https://www.youtube.com/watch?v=YiVqwoFMieg
In the description there are links to projects built with that structure, called clean architecture. I you're a beginner, maybe you want to see some beginner tutorials, see the structure there, try to understand it and gradually try to understand other architectures, like clean architecture.
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
What's considered to be a best practice for managing and handling a closed-list of countries, languages, currencies, etc?
We want to be able to consume the data across all of our services
We were thinking of having a NuGet package that will contain Enums, and to consume it wherever needed.
I've seen that some people use tables to manage that data, but since it's constant I don't see a reason for why doing it in that manner. This is data that changes (maybe) once in a decade.
Also, is there already a well known Nuget package containing some of these definitions already? Tried to search for it, but no luck.
Thanks!
If you really want to use packages to do this, then take a look at the results below. However, almost all apps I've seen/worked on generally use services or a database to retrieve this info rather than a nuget or a class containing constants.
Country Codes
This is the best I could find (with over 19,000 downloads): ISO3166
Currency Codes
Two packages with <1000 downloads: Search results for ISO4217
Language Codes
One package with <1000 downloads: Search results for ISO639
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 7 years ago.
Improve this question
A "God Namespace" is the (uncommon) term for an (anti?)pattern analogous to the "God Object", when you stuff a metric ton of stuff (mostly methods/functions) that is not related or not closely related to each other into one huge namespace/static class just so that it can be used in multiple sections of your project.
When following that (anti?)pattern, you often end up, as a C# example, with something like a static class Assets with tons of methods mostly unrelated to each other, but used across multiple places in your project(s).
I usually approach this problem by letting the next Assets grow for as much as I can bear it, and then desperately try to sort its contents out into several smaller ones based on the criteria which seems most legit, like MathAssets, or BitmapAssets, or RNGAssets, and then end up forgetting what did I put where... and make a new Assets for several new methods which don't fit into either of the SomethingAssets already cluttering up the project.
Are there any other ways of clearing up the "God Namespace"? Or will I just have to live with good old static class Assets?
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 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 8 years ago.
Improve this question
A couple of months ago I've coded a tiny tool that we needed at work for a specific task, and I've decided to share it on CodePlex. It's written in C# and honestly it's not big deal but since it's the first project I've ever built from scratch in that language and with the goal of opening it from the very beginning, one ends getting sort of emotionally attached to it, I mean you'd wish that the people will actually participate, be it criticism, bug reporting, or what have you.
So my question is, what can I do to actually encourage participation, stimulate curiosity or just recieve more feedback about it?
By the way this is the project I'm talking about: http://www.codeplex.com/winxmlcook/
You should:
Promote it where you think it would be relevant (forums,mailing lists etc.). Try not to spam though - it will create a backlash.
continue to provide updates as to create the appearance of an active project until more people pick it up.
Find project leaders, they are the sort of contributors that encourage others to contribute as well.
Blog about it and link to relevant blogs (creating ping-backs). Also leave comments at relevant blog posts.
Basically, your generic Internet marketing tactics ;)
You first have to acquire users by marketing the tool. Once you have users, that naturally means you'll start getting feedback.
One thing I noticed is your project description doesn't sell the project well. For example, type "winxmlcook" into Google, what gets shown is your project description but it's not likely to get someone to click on it.
I know I sound like a broken record constantly posting this book, but just about everything you could ever need to know about running an open source project is here. In particular, pay attention to these two chapters:
Getting Started
Managing Volunteers