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 5 years ago.
Improve this question
I have the following code files in my solution:
The configuration is stored in a json file.
The shape of the data (model) is defined as a sealed class.
The configuration has to be read and parsed from the json file and stored into a public static class, so that it is available for use at run time.
A few helper libraries needing access to configuration data.
A few console programs making use of these libraries.
How should I organize the code into individual projects. Currently the console programs and rest of the files combined are stored as separate projects. Specifically, should the model of the configuration data and public static class holding runtime configuration, and parsing of json be an independent DLL?
There are very few reasons to separate code into multiple dll's, and odds are good you don't meet any of these reasons. Separation of concerns refers specifically to logical separation, and in the .Net world this is achieved via classes and namespaces. You can use the folders in your project to automatically assign the namespaces of the classes in them.
You are better off having only 1 project per executable and 1 project for all your business logic.
Here are a few reasons why you'd want to create multiple dlls':
Redistribution and copyright issues: You wouldn't want your customers to own server code. Create separate dll for client and server code.
Performance: if your dll starts bordering the dozens of megs, you may get some performance gains by splitting it up. (as with all performance concerns, you must first test and analyze performance bottlenecks before you implement any performance code).
Versioning and deployment: If you have a very large code base, and you know some of the code is more likely to change than other, you can split dll's in order to not have to deploy more "sluggish" dll's every time.
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 4 years ago.
Improve this question
I'm in charge of porting a Java application to .Net platform.
I'm kinda experienced with C# and .Net but I've never started building things like this from scratch.
So, this application consists of two parts:
Framework: A small framework responsible for creating CRUD pages endpoints. This framework uses classes from the "business layer" as models in order to easy build pages. It basically has a FrameworkPage<T> class and we use a type T and some overridings in order to write it. Also, this framework has some endpoints of its own. Like myapp/framework/FirstPage which maps to a framework/{pageName} controller where we use a generic logic to retrieve data for that page. The important part is that this framework has its own endpoints.
Business Layer: Application that uses the above framework, has its business classes and also has its own custom endpoints for pages that are not the default framework page.
Today, in the Java project, these two are only separated in different folders. In the future we want to reuse the framework wherever we want, so it is important to keep it dettached from any business logic. To do so, in .Net platform, I think it would be interesting to have these two in separated projects inside my solution. Then, in the future would be easy to separate it and even compile it into a dll to use in another projects.
Is this the right approach? If so, how can I make it possible since I'm having two web apis applications? As far as I know about a .Net project configuration, I have only one startup project (the one that is deployed). I can set a multiple startup configuration on those guys but I could only get them to be started as separated apps: localhost:XXXX/myapp and localhost:YYYY/framework. I need the framework to go "inside" the application: localhost:XXX/myapp/framework/framework-endpoint.
Thanks!
Found one solution that suits me by using AddApplicationPart().
Basically, on the Startup.cs of my BusinessLayerProject I configure the services as:
using Framework.Controllers;
// ....
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2)
.AddApplicationPart(typeof(FrameworkController1).Assembly)
.AddApplicationPart(typeof(FrameworkController2).Assembly)
// ...
.AddControllersAsServices();
With this, if my framework controller has a route like framework/controller1 I can access it when I deploy the BusinessLayerProject
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 4 years ago.
Improve this question
I'm developing a desktop application that serves as an IDE for our customers. This application allows the user to configure and integrate our programmable devices into their products.
I'm looking for best practices/design patterns for managing persistent data in an MVVM app like this. Some data is potentially reusable between the users' projects, so I'd like to store those pieces independently, rather than in one big file. This scenario has led me to consider the way Visual Studio handles this (a .csproj file that points to the files that make up the project).
When considering the Visual Studio approach, I can easily implement an object like this for my own data and serialize it into XML. However, when it comes to opening and manipulating the files that this project file points to, I am really struggling to find an elegant solution.
For instance, I open my project file, deserialize it, and I'm left with an object containing the paths, as well as some metadata like CompanyName, ProductName, and so on. Next step: open/deserialize each of the files pointed to in the project file... But where should those objects live? How should you notify the ViewModels that the model was changed externally? Intuition tells me that there should only be one instance of any unique model to avoid issues with copies falling out of sync, but that's all I've got.
Perhaps there's a framework available for this?
There is probably a good article or SO answer to this, but I couldn't figure out how to search for it. Any advice would be greatly appreciated.
Settings that are specific to the application should be stored using the normal settings that's built into Visual Studio and .Net (Settings tab on project properties). This will provide you will versioning, upgrading, etc.
Settings that are specific to each project would need to be stored in the project itself.
To be a good corporate citizen, you should create a folder off of the user's Documents directory and then each project might have its own sub folder if it has multiple artifacts, or I guess just a flat directory if everything about the project is a single file.
The other part of your question was unclear. Are you talking about how a .cs file can be edited externally to VS and VS reloads it automatically? If so, you'd just set up a file change notification watch when you open a project.
EDIT:
View models should generally not have references to each other, unless you are referring to POCOs that implement INPC as a "view model" which I don't really. View models to me is basically the data context for a XAML view.
In terms of VMs communicating with each other, its best to keep it loosely coupled and use the messenger pattern. Most MVVM frameworks have a messenger implementation. You DI a IMessenger or whatever interface they use into your VMs and then IMessenger.Subscribe<OpenMessage>() (syntax obviously varies among MVVM frameworks, but in general you get a message of type X and add an event handler or call the send method) for example and get notifications of that type. The VM that is initiating the message would new up an OpenMessage and send it to the messenger to distribute it to the VMs that want it.
For your CsProj scenario, you would need to store those settings in the project file and deserialize.
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
I am writing a software suite which is essentially composed of two separate applications in C# .Net using WPF. Although they may look a little bit different they essentially work like a lite version and a full version of the same software package. The full version contains all of the functionality of the lite version.
I had previously done this by creating two separate applications which share a class library where all the common user controls go. But i am now wondering if there is any better design for this kind of architecture.
I was even thinking of creating one application and at runtime let it decide which version it was going to work as.
Could anyone with any experience with this type of problem please point me in the right direction.
Keep it Simple
My rule of thumb is whenever possible keep solution as simple as possible. That being said I would use the same composition you are using.
Usually break up projects like this:
Application Logic: CompanyPrefix.ProjectPrefix.Core, CompanyPrefix.ProjectPrefix.Data...etc.
Applications : CompanyPrefix.ProjectPrefix.ApplicationType.App, so some examples :
CompanyPrefix.ProjectPrefix.Web.App
CompanyPrefix.ProjectPrefix.Console.App
CompanyPrefix.ProjectPrefix.Wcf.App
Since you have two Wcf Apps might want to do something like
CompanyPrefix.ProjectPrefix.Wcf.Lite.App
CompanyPrefix.ProjectPrefix.Wcf.App
So in this example both CompanyPrefix.ProjectPrefix.Wcf.App and CompanyPrefix.ProjectPrefix.Wcf.Lite.App point back to CompanyPrefix.ProjectPrefix.Core or wherever your business logic is.
About Dynamically Loading Assemblies
There is a way to dynamically load your libraries at runtime, but unless you're dealing with a modularized system of independent components would recommend against it.
If your heart is set on it there are a lot of resources on MSDN, would probably start here. Article about loading assembly into current application domain.
Come Up with a Checklist
One thing I find helpful is to come up with a checklist to help me make decisions in case I ever get stuck. Usually ends up being something like:
Does this have business value?
Does this make debugging harder?
What are the Pros and Cons of doing it a new way versus the way I have done this in the past?
This isn't my exhaustive list but explains the point. This can really help too when you have a group of people that are largely sticking with choices for personal reasons that don't have any grounding, as well as a tool to use when you get stuck to make a decision and go with it
Dealing with Application Logic Changing (Write Clean Code)
Coming up with an over-complicated "never need to recompile entire application again" is a mistake I have made in the past. You're still going to need to deploy and compile something.
Most important thing about dealing with changes in application is to
Have Code on Source Control (most important)
Write Clean Code
Write Tests
Write Documentation ( I know no one likes to do this )
Write some more Tests
What will consume most of your time when dealing with application changes is debugging so focus on reducing the amount of time you spend debugging not a amount of time you spend compiling and deploying
For Deployment setup Continuous Integration
If you have the ability to setting up CI would eliminate 99% of the hassle of changing the application. You lose a day or two setting things up for the first time, but it is well worth it.
Check out TeamCity and Travis CI
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 9 years ago.
Improve this question
Say I have an application that is connected to a database, with its own forms that present data and allow data to be changed & entered, how would one extend the program to be extensible by a third party?
For example a third party would be able to write scripts that the user can run that would prompt the user for input. Part of the script would then take what the user inputed (integer/string/boolean) and do some basic programmatic things to it, math on integer values, concatenation on string values (and other string functions), and logical tests to trigger further user prompts etc etc, the scripting environment would also support reading/writing to the application's database.
Would this be done simply by having text files the program could run, with each line corresponding to a certain command? Then the application would read each line, figure out what command the line represents, and equate that to C# code? Are there any already existing solutions to this problem?
The question is fairly open, here some proven great extension tools:
Compiled Plugins written in C# would use Managed Extensibility Framework (MEF), a great and well designed extensibility option.
Scripted Extensions in C# might be possible soon when Roselyn is ready.
Scripting could also be accomplished by integrating Jurassic into your application.
There are several good choices if you want to embed a scripting language into a c# app. IronPython, IronScheme and IronRuby alL support the Dynamic Language Runtime so they can access objects from the host code. There's also Boo, which is a strongly typed CLR language that looks a lot like Python but can be easily embedded in a C# application and, like to the others, can interact with the host application. In general the embedding process is pretty simple - Michael Foord's IronPython site has a good example.
There's also NLua which is supposed to be a CLR friendly lua wrapper, but I have no personal knowledge of that one.
Out of all of the above, I'd expect the main thing driving your choice will be the preferences of the user base. Especially for the lightweight application you've described all of these choices should be well suited. If you wanted users to be able to do extensive programming on their own it's more complex, since the CLR ports of these languages dont usually support the same binary extensions as their C-based counterparts - for example, IronPython can't use the regular Perforce API module because it is built on a C-based binary extension module. All Iron* languages can use the same base class library as C#, though - you can import System.Windows.Forms into any of them to create GUI and so on.
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
Basically, the question is: Where (and in which format) should I store textual developer documentation associated with my Visual Studio projects?
To elaborate: XML comments are great, but they don't cover all use cases. Sometimes, you'd like to describe the class architecture of the project at a high level, add usage notes to your library or just leave any other kind of message to future generations of developers working on this project.
I'd like to add these documents directly as files into the Visual Studio project, to ensure (a) that they are available to the developer without further searching and (b) they are version controlled (using the same svn/git/whatever repository as the source code).
Currently, I add a folder _Documentation to the project and use text files, but I'm not sure if this is the best solution. Visual Studio does not have an option for automatically word-wrapping text1, and manually fixing line breaks after each change is annoying. On the other hand, Word documents don't work well with version control, and TeX is too much of a hassle to set up and teach on each developer PC.
Is there a well-established best practice for this?
1 I know that there's Edit/Advanced/Word-Wrap, but this only affects the display, not the file itself.
I just had the same issue - only I noticed that I was able to add a HTML-file. Once opened, simply switch to "Design" at the bottom of the screen.
You may want to change Build Action from 'Content' to 'None'
As it is a hard-coded HTML document, it is also possible to use inline pictures (e.g. a diagram)
Also for my purpose (programming guide, architecture description. database use examples) I opted to create a separate project (_Documentation) as a Windows Forms, as this will allow me (or a new programmer) to have a running example.
I use GhostDoc (visual studio add-on) for documentation of my project as I add classes, methods, properties etc: http://visualstudiogallery.msdn.microsoft.com/46A20578-F0D5-4B1E-B55D-F001A6345748
You have the option, in XML comments, to include a lot of data that you can then pick up with a tool like Sandcastle (site) and turn into an actual MSDN-style reference site.
I tend to use this method and just write long XML comments (MSDN comment tags) (where appropriate) using the <para></para> to generate paragraphs and explain any patterns, business reasons or architectural information necessary to future modifiers/developers. I also use it to give usage examples.
A good batch of tests (well written and named) can also really illuminate the purpose of code, acting as a spec.
I hope that might be a little informative in your research :)
XML Comments is best for documenting the particular method and not ideal for writing long conceptual content. Long XML comments could adversely affect code readability.
I liked Conceptual topic documentation feature of Sandcastle, we can create and store Conceptual documentation whether functional or architecture related and merge it with Code documentation (XML Comments). Markups which you can use in writing the conceptual topics are extendable which means we can even adhere to Enterprise templates.