I'm fiddling around with a simple Todo Blazor app. The idea is that my pages will know about an interface, ITodoService, which provides basic CRUD methods. Initially Todos will be stored in a file, eventually they will be stored/retrieved somewhere remote, using REST, like this site which provides dummy data: https://jsonplaceholder.typicode.com/
I have planned the following three projects in my solution. The purpose of this exercise is to try and keep things separated and modular.
The green, orange and pale orange are my three projects. The interface my Blazor app needs is in the Blazor project. This means FileData and HttpServices must have a dependency to Blazor. I do this in the hope to make it easy to swap out TodoFileDAO with TodoHttpService, without the Blazor app needing changes.
However, everything is started from Blazor.Program.cs, as usual, so here, I would need to register my services. This requires Blazor to know about FileData, which results in an illegal circular dependency.
I don't want the interface in either FileData or HttpServices, if it can at all be avoided.
My last idea is to just create a new project, e.g. "ServiceContracts" or something, just for the ITodoService. That would fix the circular dependency. Blazor would still have to reference FileData, though.
Related
I'm planning to program a re-usable framework that manages its own views.
To get started, I already managed to get the static library and a separate bundle (assets etc) working fine.
What I'm trying to do now is somewhat comparable to the behavior of a jQuery plugin. The main application that depends on my framework (and bundle) should define an element in its view that it can hand over to my framework as a reference. The framework will then render itself within this element.
It is necessary that the main application can handle itself how that container is being displayed (overlaying the main app entirely, or being displayed in only a certain portion of the main app...)
I was already looking at "Container Views" but am not sure if this is the suggested approach to accomplish this. Any ideas, or resources / tutorials that could point me in the right direction?
Using the approach suggested by Thomas, I was able to put it all together.
Basically, the app itself defines a UIView and hands off a reference to it to the framework. The framework is then able to put its content inside this UIView.
I have been looking for an solution for structuring my MVC5 project, but have not found anything yet.
What i look for is. I have an Main Website, which off-course has it's own Views, Scripts and Controllers, but what is special is that i like to have sub Website projects which add an menu point in the main page, but the sub website also contains it's own Views, scripts and Controllers( I have tried to draw a picture of what i'm talking about ).
The point of this is to have an structured in a easy way. But also to reuse the same views in a framework way.
You should be able to define an area in another project, found an article that explains in detail how it is done in MVC3, it should not be very different in later versions since areas and routing haven't changed a lot.
http://nileshhirapra.blogspot.no/2012/02/aspnet-mvc-pluggable-application.html
Update: you do not actually need to set up the project in the Areas folder, but you need to copy all content like views and scripts/css into there before being able to use it in the main application.
If you want these sites to actually be separate websites but only look similar, then that is what you'd need to set up. You'd probably want to decide on a single-sign-on scheme for that.
I'm looking at this MVC WebApi starter kit (for Angular/TypeScript)
Ignoring all the client side code, I noticed the author has made a WebApi that is extremely bare bones. Has has taken out most scaffolding including _ViewStart.cshtml, _Layout.cshtml, and forgoed the convention of controllers in Controllers folder and views in View folder under subdirectory with same name of controller, etc.
He added some interesting Routing and Validation classes that I havent seen before in a Core folder and put controllers in Api folder and Views directly into Views folder with an Index.cshtml at the root.
It's very clean and barebone project structure for a standalone web api that will do nothing except serve data to a client heavy application. I kind of like it this way but before jumping ship I'm wondering what drawbacks this approach has and if I'm actually giving up any core features of the framework by doing it this way. For example, clearly MVC Areas are being given up here in favor of flexibility to create your own view folders structure and seperation of application sections (I'm okay with getting rid of MVC Areas I rarely used them anyways). Another thing is I don't think a Controller action method can return View() and it will find it in the Views folder by convention of the controller name. I'm also okay with that since I will only be serving JSON data and will use 100% client side templating.
Are there any other core features that are being abandoned that I'm missing that may make me regret going with this project structure?
When I create Web APIs that are hosted in IIS, the only files in my web application are web.config, global.asax and global.asax.cs. Everything else is not required.
Take a look at this template if you haven't already before you decide how to structure your ASP.Net MVC / Angular project:
http://visualstudiogallery.msdn.microsoft.com/5af151b2-9ed2-4809-bfe8-27566bfe7d83
You can always add components into your project later, so I wouldn't seat it too much. I like to start with a lean/mostly empty project first and add things myself so that I fully understand what I'm adding.
ok, i know there are a lot of posts online that specify how to do iterations with MVC.
my question is slightly different. when i used to do iterations using WebForms, i was creating one thing only and finishing that one thing till the end which was including the deployment on production.
for example, i was creating a webpage and deploying it, then i create the second page and deploy it. so .dll files were added to my bin folder while the previous dlls remain untouched. at the other hand, when i was making a change latter on, there was this one file that needed to be replaced on production.
now here is the question, how can i acheive the same thing in mvc? beause it just doesn't deploy each page into an individual dll. each time that i add something i have to redeploy the application dll which is not really wise! i played around with deployment options in visual studio but no luck!
There is nothing preventing you from putting controllers and other code in separate assemblies and dropping them in an existing application. Like any ASP.NET based application an MVC application will automatically restart if you add or modify any file in the bin folder or modify web.config.
If you're using Razor you can use RazorGenerator to generate code for your views and compile them into the same assembly.
You may need to write some additional logic though to get routes, model binders etc. wired up correctly.
For a more structures approach to compose the application of separate modules, you may want to look into portable areas. This is an extension to ASP.NET MVC that allows you to package the entire module (including views, css, js etc.) into a single assembly.
First thing, you have to work on the title of the post, it does not match the content of the post.
In asp.net mvc u can choose to deploy only what changed. I.e. If you only changed the .cshtml file, then you can just replace it with the file in production. However if you change any controller class (C#/Vb code), then you will have to upload the web project dll file too so that this new changes are available in the production env
I've got the following project setup
Project A (main)
Business
Data
View (asp.net mvc 3 project)
Project N
Business
Data
View (asp.net mvc 3 project)
How can I call from Project A the View in Project N and from N back to A. Essentially what I'm trying to do is package each Project N to have its own individual MVC as it comes from different sources and plug it in to the main project and then just have it navigate to the correct view.
Can this be done? Or is there a better way to do this?
You could write a custom virtual path provider. Here's a nice blog post which shows an example of such a virtual path provider allowing you to embed Razor views into assemblies as resources and reusing them in multiple applications.
Unfortunately without a custom virtual path provider, you cannot cross reference views between multiple ASP.NET MVC applications. This simply is not allowed by the default provider which looks for views only inside the current application.
I do sugest another approach if possible. if I understood correctly, those projects are somehow ike plugins but they are not standalone applications.Also they now about each others so they are coupled. It's, let's say tricky, but I would use only 1 asp.net mvc project (the web ui). All the UI bits which belong to other projects I'd make them helpers (pretty much widgets). This means, that each project contains only the helpers which will be used to construct a view.
I think it's a bit of an architectural problem if you only want to keep the views in each project just for the sake of hosting them in a different assembly. Going the widgets' way it might seem mkore work, but I think you gain the most control and the separation level you want. The only thing is you don't have full Views defined, but why you would want to have full Views (partials, layouts) in separate places if they will be used in one place only?!
Now, if each project is indeed a plugin, independent of other plugins, then going with compiled views is the best way. But if Project B knows about the view of Project N, then I think the above solution is more suitable. That or the whole app is too over engineered. Separation is good when it doesn't create a whole new jungle to navigate it.