I have built and application in ASP.NET MVC, which started out orignally as a way to learn the technology. However, the application (and my knowledge of MVC) have progressed and I would like to use parts of the functionality I have created in other applications. Eg I would have 2 websites both wanting to use the same News Control (CRUD) model and controller methods, but with their own unique Views. I suppose my questions are:
1. Is this going against the principles of MVC?
2. What is the best way to achieve this?
3. Is there a "best practise" way to re-use my exisiting functionality?
Thanks in advance for any answers.
Depending on your exact requirements I'd recommend you take a look at Rob Ashton's series on multi-tenancy in ASP.Net MVC, and also the portable areas part of MVC Contrib.
You could setup a Visual Studio solution in which you would have a common class library project containing models, controllers and data access and two web applications containing only the views and CSS of the two sites both referencing the same controllers and models.
Hopefully most of your logic is already separated out, but you can also pull your controllers out to a separate assembly, I believe:
http://dotnetslackers.com/articles/aspnet/storing-asp-net-mvc-controllers-views-in-separate-assemblies.aspx
Reuse is a really central part to the concept of MVC. It's very common in production MVC sites to have a separate assembly (or assemblies) for the Model. It's somewhat less common (but still done) to do the same for Controllers. The S#harp architecture project (for example) uses a separate assembly for everything, leaving just views, content, and global.asax in the Web assembly. It's all good.
Another thing you might consider is the use of Areas, which are like mini-MVC apps that you can reference in your 'main' app. It's a great way to package reusable pieces like you describe.
Paul
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 started a project using Asp.net core 2.1 and read several articles on the subject.
Asp.Net Core in the new architecture, as well as the previous, while using Razor pages, as in Asp.Net also allows you to write code to behind the page.
1- I think that the best place to inject dependency to the project is the controller classes. I didn't really understand what it would be like to write to code behind of the page in the new architecture. Also, if we look at optimizing usage, we should add re-dependency behind the page. What is logic
2- When I was dealing with the project, I realized that there is no relation between the Microsoft.AspNet.Identity.EntityFramework.IdentityDbContext class and the Microsoft.AspNetCore.Identity.EntityFrameworkCore.IdentityDbContext classes. If we want to upgrade any old Asp.Net project, is there any document related to architectural requirements with the reasons and best practices (as in the case of the DI mentioned above)
I don't have a problem with building the project, I'm just writing
here to document this topic in order to better understand it and not
to waste unnecessary effort.
please right click on Area > add new Scaffold item I guess if you are using VS 2017 pro+ you might get a list of pre-defined RazorPages you can add, I can say they are mostly related to Identity actions like login, register, change password, ... you can have them with minimum amount of effort on your application.
for my case if I am not going to implement a complex identity model or if I don't want to have something other than asp.net identity for my application membership the Razor Pages are the fastest way of doing that , generally, RazorPages are compared with Mvc ViewComponents (personally I don't like to use it frequently and application-wide) (i think razor pages are using MVVM pattern)
long story short, I believe that the razor pages are the fastest and the more organized way of doing some small features in a project or even doing small projects but imagine you have too many actions in a big project, then you will have tons of razor pages which will be so hard to maintain.
I can recommend that go for mvc approach and use razor pages as needed, for both cases you can still inject your class/interface either to controller constructors or Razor page constructors and still using built-in asp.net core DI (services.AddScoped, services.AddTransient, services.AddSingleton)
here is the source code for Razor pages, you can look into it if you are in the mood ;)
https://github.com/aspnet/Mvc/tree/master/src/Microsoft.AspNetCore.Mvc.RazorPages
I'm looking for the proper way to organize code and projects in this simple scenario in ASPNET MVC.
I have two different solutions, which are MVC Web Applications. I want them to have a common icon or other ui component which is a user avatar / login / logout form. This should be the same across both solutions.
Sharing the authentication / authorization code should be simple enough. I will just move that into a project and reference it in both solutions. But as far as the view piece - I'm not sure. Can I create a partial view in that third project and render that in both the solutions? Is that the best practice or something else?
A good way to organize a project is to create a solution and in this solution have other child projects.
Example:
School
1.1 School.Web
1.2 School.Domain
1.3 School.CrossCutting
Within the project "School.CrossCutting " You will put classes that can be added as a reference in any project.
Another tip is to study Domain driven Design (DDD).
I want to create an application which i want to work both on web and windows for which i want to make seperate presentation layer. first of all i want to know, Is MVC is only for web applications?
By all means no. Check out this quote from http://blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc/
The Model/View/Controller (MVC) triad of classes [first described by
Krasner and Pope in 1988] is used to build user interfaces in
Smalltalk-80.
When I was in graduate school we used MVC for Java apps...
Not necessarily only for web, depends on how you use it. It's just a framework that should work on both. Example, iOS development is also done on MVC style. But if you're using WPF/Silverlight, you should look at MVVM rather than MVC.
As far as i know MVC gives you more command over building the html. User MVC if you want a clean and more controlled html output. if you are developing a business application set-up a a solution and DAL and other business logics layers in class library type projects and then build separate user interfaces for both web and desktop. ASP.NET will be best if you don't want more control over output HTML.
We have a large MVC .NET website for a hospital; it has a Doctor Portal, and a Patient Portal. In essence it is two sites, with very little feature overlap. We outsourced the Doctor part to a Vendor and now we are creating the Patient part. I am recommending that we create two separate MVC projects since we are creating the Patient portal from scratch and don’t want the headache of integrating within the other code. Control, Route clashes etc. There are already 100 routes in the Global.asax for the doctor site.
The Director is somewhat technical and wants me to explain why I want to create another project. I simply don’t want the headache of having to work in other code, within the same view folder, and control folder. What are my options? Am I jumping the gun, and should just stick to the current project. Also the doctor site is live and we are adding the patient part. Does MVC/.NET offer a workaround for this?
This sounds like a good case for using MVC Areas - a feature added in MVC 2. Check out this MSDN article for more information.
From the article itself:
... However, some applications can have a
large number of controllers, and each
controller can be associated with
several views. For these types of
applications, the default ASP.NET MVC
project structure can become unwieldy.
To accommodate large projects, ASP.NET
MVC lets you partition Web
applications into smaller units that
are referred to as areas. Areas
provide a way to separate a large MVC
Web application into smaller
functional groupings. An area is
effectively an MVC structure inside an
application. An application could
contain several MVC structures
(areas).
One of the benefits you'd get by using two different projects is that if one part of your system falls, the other doesn't. If everything is chained together you might bring the whole thing down.
If they're on separate projects (separate servers,etc.) then your patient portal would survive; and as you say, the patient portal shares very little with the Doctor portal.