So I am trying to get more knowledge on the Architecture/Infrastructure of an application and want to build simple applications, just to learn.
So what I was wondering is the following:
If I have multiple applications which have functions that are almost same in every application, how can I move this code to 1 place and let all applciations use it.
Let's say the way of logging in. You preferably want to build it one time and maintain it at one place. All updates should be done in one place.
Should I use an Api, nuget, shared library or something else?
The database for each application should be different.
This is a general question, but I am coding in C# .net
Related
I am writing a C# application with Visual Studio that is divided in several modules (namespaces). Every module of course is going to be in charge of some particular function. For example there is a module that will deal with calling some firmware some place else, another module that will deal with just the UI with the user etc.
So far I have no problem doing that. But while writing the first module, I realized that perhaps the classes that I create for this, could very well be used for other future projects since their architectures seem similar.
So I am wondering if it would be a good decision to:
write a separate DLL that deals with all this functionality from scratch and then call that in my project
or just write the project, make it work and then later separate the particular module and shape it like a DLL.
You have to look at all the options and consider everything.
If you create a separate library then you need to be sure that you know all the requirements ahead of time, so that you can keep the library as stable as possible. As, each time you update the library you will need to update all of your projects which use it.
Creating a library will be at least little more work initially.
A well designed and developed library will give you the ability to be able to just drop it into a future project and be sure that it will do what you want.
A badly designed one will mean that you keep going back to it to make changes time and time again and have to keep updating all your projects, or maintain backwards compatibility which means you could end up with multiple different versions of the same method. And end up with something difficult to maintain and update.
You have to weigh all of this up against the advantages you would gain by using a library.
My experience, is that if you need to do something twice then often copy and paste is better. If you need to do it more than that, or sometimes if it is quite complex, then a library starts to pay off. But still for little things copy and paste is still easier, quicker, and lighter.
Updated.
Updated the question since it looks little ambiguous and not the answer i was looking for.
We have a huge .NET application running on MVC and angular. It has multiple projects under the main solution. .
We also have a replica of that application in Node.js for front end developers.
It looks something like this :
What happens is - Front end developers make changes in Node js solution (like js or .less files or controller) - make changes and move those changes to .Net solution which is the actual live project.
Off late - we have issues with developers working with two different solutions (Node and .NET) and keeping two copies of assets everywhere.
We ultimately decided to combine them and bring the whole Node.js application into ours .NET Solution as 6th project.
Something like this
Wondering if anyone has previously done so - adding a .NET application with existing Node.js application. If so any pros and cons to consider.
Some points to note - the Nodejs project and .Net project are completely independant of each other. The idea is to consolidate the applications so that We can either run the .net application or UI application from single solution.
Eventually, we will consolidate all the assets to just one project so that - we dont have to do duplicates.
Also, would appreciate any links where I can see how to start merging these two applications.
You definitely want to look at JavaScript Servcies. Building Single Page Applications on ASP.NET Core with JavaScriptServices.
Made for .NET Core, but you can run .NET Core on Full .NET Framework, which should make it easier to migrate to.
What I think you have is, say, a production version in .NET and a development environment in node.js for developers which prefer that.
At the company I work for, we use AngularJS for our front end and .NET/Entity Framework back end and it works pretty well.
I'm not sure if you are integrating some sort of JavaScript back end in with it or not. Assuming you are going to stick with a .NET backend and a JavaScript heavy frontend, it should be fairly easy.
That being said, nothing in this career is truly "easy". I would recommend using an AngularJS frontend as it has seemingly endless functionality.
Some minor suggestions if you choose that route is to check out John Papa's style guide. great reference for writing AngularJS. Make sure you have consistent naming, especially in Visual Studio as AngularJS can be a little moody.
I prefer to bind values to the view when working on AngularJS, e.g.
vm.title = "Data I want to bind"; in the view: <h1>{{vm.title}}</h1>
If that renders as {{vm.title}} instead of Data I want to bind you know something isn't working. I prefer catching it sooner rather than later.
Dependency Injection is another thing to be careful with, the style guide covers it as well. Basically if you minify your AngularJS files and the minifier removes the information required for DI, your project will break. I've been down that rabbit hole a few times.
If you aren't intending on using AngularJS then forget I said anything. I was just exercising my fingers. I hope that helps shed a little light on your decision.
I currently have an asp.net console application which simply retrieves a lot of data via an API from a remote server and, using Entity Framework, saves it into an SQL database. The application takes 3-4 days to run and I run it manually once a month or so.
The project is separated into a Models class, and a Repository class as well as the application itself.
I need to now build an ASP.NET MVC web application which allows users to view the data that has been retrieved and am looking for advice on how best to structure this.
Do I create a new ASP.NET MVC project in my solution and set that as the start up application, referencing the same Models and Repository classes? If so, how do I then run my console app? Or is it best to keep these as separate solutions, just referencing the same database?
Is there a better way of doing this as well? (ie, is there some way the console application can be rebuilt as being part of the front end and use queues or workers to fetch the data regularly?)
Thanks for your help,
Robbie.
Same solution. Different projects. By being in the same solution you gain the easy ability to reference shared components. I would actually recommend breaking out your entities, repositories, etc. into a third project, a class library, that then both your console app and MVC app will reference.
If you don't put everything in the same solution, then you're either stuck in DLL hell, where you have to build your project and manually copy the DLL into the other project, add the reference, and then keep everything up to date when you make changes in that DLL. The more projects that get involved, the greater the entropy and greater the likelihood that your projects all end up running on different versions of the DLL.
Another option is to create a Nuget package containing the shared components, host it in your own private repo, and then add it to each project that needs it. However, while it's pretty easy to set all this up, it's not 100% frictionless, and you will have to remember to repackage and republish the Nuget whenever you make changes, and then individually update the package in each referencing project.
Long and short, same solution is always the best way to go unless there's a very good reason not to. It's the only "it just works" approach.
Personally I would keep these as separate projects and separate solutions that just reference the same database, but move code that can be shared by both solutions into a separate class library.
The way your web application will present your modeled the data will most likely be very different to how your console application will use it; so using the same models and repositories will most likely further couple your web application to your console application.
This is very similar to the way micro services work, where the micro service acts and grows independent of its consumers (in this instance, your web application) and only communicate via a clearly defined API.
i have a project where i do something i have same copy from another who have do something in it later i have a thing to do currently.
so that's three copy and i am unsure that i am not confused with it. sometime i call wrong copy for finding the thing i want from them.
without using any software outside our office window any trick to manage all project or how i can manage them and make them one copy.
the same problem with some other problem come with when the same script used in two software , website who are used same script with have a small difference in both.
so i want to know how exactly all other manage them. i want to have a answer with .net plateform.
There are several source control solutions that have plugins to integrate directly with Visual Studio. I would recommend looking into Subversion. Currently at my office we use Vault, but it has some short comings, especially when it comes to renaming or moving a file and then editing it prior to a check in.
http://ankhsvn.open.collab.net/
http://www.sourcegear.com/vault/
I recently started a small pet project. It's written in C# with ASP.NET MVC3. As it's grown, my needs for source control also has grown. Here's what I've done:
Day one, I placed my project in a Dropbox folder. That way, I could reach my project files from all my computers (and even my iPhone).
A few weeks later, when I first had to make some serious changes and neede a fallback, I created a Mercurial repository in my Dropbox folder and commited all my code. I've got a blogpost on that here: http://csharptutorial.blogspot.com/2011/06/using-dropbox-with-mercurial.html. Mercurial is a great versioning system, because it doesn't require a server installation and your repository is copied in full to all locations where it's checked out.
Now, I'm looking at moving my project over to BitBucket (http://bitbucket.org/) where you also share and discuss code with others.
A good alternative to Mercurial is Git, using github.com in stead of bitbucket.org. Both have a learning curve, but they both represent modern version control tools and is well worth having a look at.
Source control and discipline.
You need to get an approach and method for managing your source. A source control system is essential for this. I use SVN and Ankh, as does Clayton.
However, you need an approach for using this. I always have branches. You can have development branches and merge these changes into a release branch when your code has passed all the tests. This way takes a discipline and time, but you need to do this to build quality into your system.
I have a challenge similar to creating-my-own-plug-ins-for-my-own-project-in-c# and late-loading-a-net-plugin-dll, with the added headache of being able to specify a version to use. My current idea is to simply use console apps, with folders named by version. I'd then find the folder and load the console app by known name, using Process.
I'd like to avoid having to write out and read in text, which is the only real way I can see for a console app to talk to my 'control' windows forms app. Using dlls seems like a possibility, but I haven't done much with dynamic loading before and it seems rather messy either way.
I've had a quick look at the Managed Extensibility Framework, but it's still under development, and aiming for .Net 4.0, which I might be able to look at, although I need this solution relatively quickly.
Any other ideas out there for accessing a specific version?
In the end I just used a well-known folder structure to contain different versions of console apps.
No, it's not clean, and probably not the best way to do it. However, I don't have control over the console apps/dlls, and this works without being too much to explain to the researchers I work with. They know research, C# is just a tool.