I have a question regarding development architecture and what would be considered to be the ideal organization of code and logic.
I am working in a company that has multiple C# solutions, with multiple projects accessing multiple databases. Some projects access only one database, some others access all of them, and so on.
Right now, the management of each database is made inside each project. I have been thinking about creating libraries to unify all this process.
Could somebody give me some insights regarding this? What would be the best way to work on this?
I've been thinking about centralizing all the Database logic inside a solution, with separate projects for each Database. This way I can create Class Libraries that will compile DLLs for each of them, that can be referenced between projects and solutions.
What do you think about the concept above, specially working using Entity Framework?
Thanks in advance.
We have a very similar situation.
For each database, we have a separate class library project. The project contains the context, entities and associated migrations.
Each product references the class library or class libraries that correspond to the database(s) it works with.
When we first started, each developer would check out the class libraries, build locally and reference the locally compiled DLL (which we copied to a known location with a post build event). It turns out that it's remarkably easy to setup your own NuGet server and publish updates to that server. We transitioned to that solution a few months back, and it works wonderfully. There are also a number of hosted NuGet providers.
This should be the way to go yes. I would create a solution for that purpose, abstract all database connectivity logic there and then use it from other solutions just handling different ConnectionString's.
I recommend to take a look at NuGet if you already haven't, you will have many advantages with this package manager for sure!
I think one centralized database which has all the common entities among your applications can be useful here. if you want to keep the other databases is fine too, you can use replication to transfer data from master database to other databases and consume them in their applications
Related
I try do my projects with clean architecture. I use Entity Framework. Everything is good and easy to know. I have structure like this - Domain, Application, Infrastructure etc. I create my project without any big problems - WebApi project. Now I would like to add Blazor server side project. What is the right way? Only add Blazor project to my existing solution? Here is few problems for me. I will have the logic of two applications linked (handlers). And I have some nuget packages which contains webapi specializations. When I create own solution for blazor app here is only one problem. The duplicate of dbcontext. I need "duplicate" (I can use only 2 tables if I need) domain project with entites and dbcontext in infrastructure. But then it work's good and it's clear. But I don't think it's good way to duplicate domain project. And where is stored migrations?
I know if projects will microservices it will be super clear and it's makes sense. But when I have monolith and would like WebApi and Blazor app with one database what's right way?
What is the right way?
As always - it depends.
In the Uncle Bob's article on the Clean Architecture the following point is present:
Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
If your Blazor App can be considered just another UI (without major changes to the business rules, though it can have some specific use cases) then it should be a part of the current solution.
I was Studying a course in PluralSight in clean-architecture by Gill Cleeren, they the Blazor project to the same solution
The point of Clean Architecture is that you do not have to duplicate shared logic. Blazor server project is a "front-end" layer at the edge of your application. If implemented correctly you will reference the other projects just like your WebAPI does.
Try to add a Blazor Server project to your solution and reference the Application/Infrastructure/Domain projects that already exist and you should be able to re-use all the exisitng logic.
Blazor (and WebAPI) is nothing more than a way to present your data, so keep it that way.
I'm planning to create a website using ASP.NET Core 2.0 , Entity Framework Core, Angular.
I was planning to create one solution with different projects (core, data layer, UI ...etc ) however the client quoted "this is a bad idea, please create separate solution for your UI and API).
how can i create multiple solution and still let them interact with each others?
What is the best practice?
If i create separate solution for my UI, how can i communicate with EF context which is in a different solution?
Solution is basically just a logical container for projects, so you can create multiple solutions which will reference the same (existing) projects. This is quite common for large solutions like for example Xamarin.Forms - you can have one large solution with all projects and then have smaller solutions for developers who need to work with only a subset of the projects.
You can add existing project to your solution by right-clicking the solution in Solution Explorer and choosing Add - Existing Project.
I think your client may misunderstand what a solution is. Grouping your projects in a solution only affects your workspace in Visual Studio, it does not mean that your projects have dependencies between them (unless you explicitely say so in their references)
The only way I can imagine this working is to deliver each solution as a set of microservices.
However, now your architecture is different. Only one of those solutions is going to be publicly exposed. The others will need to sit behind a firewall to ensure that they can't be reached by external users. But all of them will have scalability and security concerns.
So you'll have a set of data services that encapsulate Entity Framework and expose the data through a Web API, and a business logic API that is reached over a Web API, and then your UI (which should include Angular).
APIs calling APIs. Welcome to microservices.
how can i create multiple solution and still let them interact with each others? What is the best practice? If i create separate solution for my UI, how can i communicate with EF context which is in a different solution?
Answer :
Create base solution first ex : BaseSolution.sln then go to that solution file explorer and create API,UI folder.
Now open visual studio and create new solution ex: ApiSolution.sln save it under API folder and add web api project inside ApiSolution.sln and save.
Now open BaseSolution.sln and right-clicking the solution in Solution Explorer and choosing Add - Existing Project then choose web api project from ApiSolution.sln then add it.
You can follow step 2 and 3 to create more solution and add it to BaseSolution.
Web api connect through HTTPClient with another web api.
I've entered a project that used the architecture where all the utility classes were stored in the same project as the plugin. That's fine as long as there's only a few plugins with different utilities.
I noticed, however, that as the number of plugins has grown, many of the individual utility classes overlap. So, I'd like to pull out all the utilities into a single, separate project. My fear is that it's going to be too complicated to maintain once I'm leaving the customer as they're not technically keen.
The best solution I've got this far is following this blog facilitating ILMerge. However, I wonder if there's a simpler way. The optimal approach would be if I can make the CRM "see" the utility DLL just by uploading it. Can I somehow register a non-plugin, non-executable DLL that the plugins can refer to?
No, if you are using CRM Online this is not supported.
If you are running CRM On-Premises you could deploy the utility DLLs to disk or register them in the GAC. In either case you need to make sure to keep them updated on each CRM server - if there is more than one.
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 recently started transforming all tables from our Oracle production into models so I can start using an ORM. I chose Castle Active Record and can really start to see its potential in making my life easier. Since many of the applications I work with utilize the same tables. I figure it would be nice to create a separate library.
My thinking is that if I can successfully separate the database work, table relationships and querying then I can reuse them to my hearts content from project to project. I know for the most part how to create new entities, link them and query what I need based on what is mapped. As of now I have a very simple class library. I could then include generic functions that could be used to query a lookup table and return an id-value pair to populate a dropdown, for example.
Could you please give me some tips and/or personal experiences to achieve this? This will be my first time attempting to create a reusable library of any sort.
Thank you.
I would:
Keep it simple.
Document its public interfaces/methods heavily, especially since you'll use it in multiple projects.
Keep it in source control, which you should be doing anyways, so all projects can easily get updates.
WCF is a popular way to achieve this. Basically you make a bunch of WCF web services that provide access to the data access functions.
This is an ideal place to use interfaces. Store all of your interfaces in a very small, isolated .dll - and you can distribute that. Your consumers can then deal with their own implementations (if I'm understanding you correctly). You could also deploy a standalone component that just has your data structures too.