In the MVC folder structure, where should general class files reside? For example, I have a class that determines the right DataContext to use, so I'm not reinventing the wheel in each of my controllers. Should it live in the Controllers folder even though it's not a controller? Should it be with the Models because it's database related, even though it's not a model? Possibly the Views\Shared folder? Or is Content the catch-all folder for that kind of stuff? I'm sure I could put it anywhere, but I was wondering where the "right" place is.
It's not a controller, content or a view, so don't use those. It sounds most closely related to your model, so you could put it in model under a subfolder called "Helpers" or "Utility" or some such. Or you can add another top level folder called Services and put it there. That's where I put all my app logic, the middle man between the controllers and the model.
If you look at Rob's MVC Storefront: Separate class library project (like Commerce.MVC.Data)
If it could be useful by itself (think of a command line tool built around it), put it in the Models folder. If it is used only as a helper for controllers, put it in Controllers folder.
It really depends on what it does, if it accesses data it should be in the Data Access Layer, otherwise you can put it in the controller folder.
Have a separate DataAccess assembly, make that class internal and call it DataContextFactory.
dmajkic,
Why separate it out into its own area? If its BLL code it should be in the controller folder, if its DAL related item it should be in the Model. I can understand if a project gets huge and you want to create some subfolders, that shouldn't be an issue. But placing code in another tier really defeats the purpose of MVC don't you think?
Related
I'm trying to understand how to do an Asp.Net Core application (3.0) looks like a Screaming Architecture folders and files conventions.
I read about it but and started with an empty project. The folders are:
Controllers
Views
Models
I want to make the web application working like
Customers/Controllers
Customers/Views
Customers/Models
Is it possible?
Thanks in advance.
Both controllers and models are referenced by namespace, so their physical file locations have no bearing on anything. Controllers are dynamically loaded regardless of where they are in the project or even if they're in the project at all (i.e. a controller from a referenced library will automatically be loaded). Models are entirely code-based, and you'd just add a using statement with the namespace of the model(s) to access them in any other piece of code.
Views, however, are very much based on the filesystem, and changing the main folder they're in from just Views or Pages directly in the project root will cause the convention-based view loading to fail completely. You can always add additional view search locations, such that it will look in /Foo/Views and /Bar/Views, etc. but that's really not recommended.
All that said, though, there is a concept of areas, and you can break down your controllers, models, and views that way. You'd simply have to have:
Areas/Customers/Controllers
Areas/Customers/Views
Areas/Customers/Models
In other words, the Areas prefix would be mandatory.
Where is the best place in the project directory for the controllers for Shared partial views?
I have found similar question to: ASP.NET MVC: Correct place for Partial Views?
I can't decide if it is better to do something like /Controller/Shared/CONTROLLER_FOR_PARTIAL_VIEW or just create its separate folder like /Controller/CONTROLLER_FOR_PARTIAL_VIEW
The partial view is specifically for dropdownlistfor, and the model wont be used for anything other than to populate the dropdown. So if a site has many dropdown lists or just partial views in general, a shared folder seems to be the best option. If the preferred way it the Shared folder, do you use one controller for each partial view, or one controller for all partials? I appreciate any thoughts or feedback, thanks!
EDIT: To be clear, I m specifically asking about the directory for the CONTROLLERS not the VIEWS. Thanks!
In one sense, it doesn't matter. There is no true standard or convention for this, so you have the freedom to do it however it makes the most sense to you and your application.
Having it under something like Controllers/Shared could make sense, if there's enough of these that that is worthwhile and it adds value to keep them separate from regular controllers. However, in terms of a project, everything is essentially shared, so there's no true distinction here. Personally, simply having it named something distinctive is probably the best route. For example, I have a number of child actions in one of my projects that are used in various parts of my layout. As a result, I created a LayoutController to house these.
The one thing to keep in mind is that, if you're using standard routing, any controller will be available to the routing infrastructure, regardless of where it's located in your project tree. You'd have to pretty much just know how to get to it, but if you named your shared controller something like SharedController, then with standard routing, its actions would be available via /shared/action. For things like child actions, this is easily solved by using [ChildActionOnly]. By adding that attribute to your child action, it will be divorced from the routing infrastructure for URL requests. Internally, MVC will still be able to get to it for the purposes of rendering it for a view, though.
Projects I've been on it was at /Area/Controllers/SharedPartialController.cs and with that naming the view was at /Area/Views/SharedPartial/_MenuDropdown.cshtml
Hopefully you're using "areas" in your MVC project, in which case I would suggest doing one shared controller per Area.
I.e. /Order/Controllers/TabsPartialController.cs for one that relates to Order area, and then /User/Controllers/NavTabsPartialController.cs etc.
I want to develop my wpf project by using MVVM pattern. Should I create new folder to separate Model, View, ViewModel or create new project for each? Which one is good practice? I downloaded sample project, some of project have separate folder for it and some of have separate project for each. I referred this link.
But this isn't clear my doubt. I am asking whether creating new projects for Model, view and viewmodel is good practice or creating new folder?
This is a duplicate question, as you can find the answer here by Sheridan to be most helpful.
Basically you need to determine what the overall size of your project is going to be. If you plan on reusing pieces, you might want to to multiple projects and different levels of folders. This also goes for if you plan on providing parts of your application as an API, then you will probably want to use multiple projects.
For beginners, I would suggest you start small and put everything in one project. To learn MVVM, don't focus on the project structure rather how WPF and MVVM work. Solution structure can always be revisited after you've understood how MVVM is working.
EDIT
The answer is no, you never need to create folders or separate projects for your project. Just realize that creating new classes under a different folder will also use that path as a namespace. So if you create a ViewModels folder and add a class to that folder you will see namespace WpfApplication1.ViewModels at the top. This also means that you will have to pay attention to locations of namespaces in your XAML files. If you wanted to reference a type in your ViewModels folder in a XAML file, you will need to do something like <xmlns:vm="clr-namespace:WpfApplication1.ViewModels">. The downside is if you have folders in ViewModels you need to reference that namespace in your XAML also. So if there was ViewModels > Basics, you would need both namespaces in XAML since you can't reference all sub-dirs in one xmlns declaration.
<xmlns:vm="clr-namespace:WpfApplication1.ViewModels">
<xmlns:vmBasics="clr-namespace:WpfApplication1.ViewModels.Basics">
The alternative is using folders and renaming the class namespaces to just plain old namespace WpfApplication1 then you would just need a single xmlns declaration and can access all types in your application.
<xmlns:app="clr-namespace:WpfApplication1">
So, don't complicate things if they aren't needed; and typically nothing in the learning stages will be so complex it needs multiple projects. Folders are optional, but understand the side effects/workaround if you use them.
This will really depend on your use case. Do you have a scenario in which your views, view models and models may be separately reused in some other project? What i mean by that, for instance, do you have a scenario where you would use only your models in some other project. If yes, then it makes sense to create separate projects so they may be reused. If that is not the case however, it is better to keep them all in one project.
Folders are only for creating the Structure and for easy Identification. It is really not necessary to have Folders for View and ViewModel.
I would normally create folders each for view, ViewModel etc. Then I would give descriptive names to views and viewModels classes. If you have several pages I would suggest having sub folders. All goes in one project. But this is my preference.
eg:
View>Sales> WelcometoSalesPageView.xaml
ViewModel>Sales> WelcometoSalesPageViewModel.vb
I have spent a few hours searching around however I must be either searching for the wrong thing or doing something wrong because I can't seem to find what I am looking for.
This seems like a newbie question (and it probably is). I have created a C# file called dbconnect.cs and I am now trying to figure out how to connect everything together. My file structure is as follows...
-Controllers
-AcountController.cs
-dbconnect.cs (not sure if this should go here or in models folder)
-HomeController.cs
-Models
-AccountModels.cs
-Views
-Account
-Home
-About.cshtml
-Index.cshtml
-Reviews.cshtml
So basically what I am trying to figure out is a couple things.
The proper way to use databases with MVC3 (should my file be in Controllers or Models)
How to connect my dbconnect.cs folder with my View so I can troubleshoot it.
Any help / useful documentation sites is much appreciated. Thanks in advance.
EDIT:
I am not sure if this is relevant or not. I am using MySql and not SQL. Also I am assuming i need to use using dbconnect; but I am not sure how to integrate it with the HTML files.
For databases, you should use Entity Framework.
For views, each controller should have a views folder with the same name (eg, ~/Views/Home/ for HomeController), with one view file for each action.
You can also exlicitly pass a view name to return View().
You should really try to understand the functionality of Models, Views, and Controllers.
Start with understanding Controllers, then Views, and then Models and then everything else will be clear:
=================Controllers=================
Controllers are the middle-man between your User Interface (UI) and the "Back-end".
Inside of a controller, you define what happens when a user requests something from a certain URL.
Controllers usually are tied to the URL.
Meaning your HomeController function TestFunction will RUN (GET) when you go to the URL:
/Home/TestFunction
=================Views=================
Views is the User Interface. The HTML. The "What it will look like"
A view usually gets its "data" from the controller.
What is this "data" - well that's the model:
==============Models=================
The data between being transferred to the View (UI) from the Controller.
Your code should get data in the controller and should return as a model to the view
By the way, I would use EF (Entity Framework) to manipulate the data and make calls to the EF from the controller (usually via a HelperClass)
Good Luck!
Assuming dbconnect.cs contains class definitions within a namespace like this:
namespace MyProject.DbConnect
{
public class Repository
{
// ...
}
}
In your controller class files you can simply add using MyProject.DbConnect to reference anything from that namespace. And if you want to do that from the views, simply add #using MyProject.DbConnect
That being said. You really should be using a mature ORM like Entity Framework.
maybe i am wrong but i seriously i don't like the current structure of MVC application, and i think on big projects it will cause trouble to maintain.
so is there a way to group related Controllers,Views, Models together, like if i have gallery Module i want all it's Controllers, Views, Models to be grouped under Gallery Folder.
Areas sound like what you are looking for. This will let you group controllers/views/etc. Unless I misunderstood the question?
Phil Haack discussed this here, it's the same issue I've faced and have yet to overcome correctly.
From the sound of it you're moving against the basic principals of MVC, that being the separation of Model, View and Controller rather than your desire to split at 90 degrees to that by using modules.
I'm not entirely sure what benefit you would get from splitting it in to modules any way since I would expect you to have one GalleryController. Where you are likely to have the most 'entities' needing grouping is with the views, possibly one or more for each GalleryController action, but they are in their own folder which gives the sort of functionality you are looking for anyway.
Finally there are the models. Obviously I don't know your project so I don't know how it is laid out, but the Models do not usually exist for the use of one Controller (or module in your case). For example - I have Models for Users, Companies, Vehicles, etc, etc. These models are a shared representation of my data structure and have nothing to do with modules as a user may see it looking at a web page. I can't split them in to modules because the whole point is that they are shared by the entire application.
So...in reality it is the Views which can get a bit messy, but they are already split in to folders based on their Controller. Having said that you can move them around a bit if that suits your needs better. For the rest of it there is no need, either because you shouldn't if you want to use 'proper' MVC (i.e. modular Models) or there's no need (i.e. only one Controller). And if your controller gets too big just create a separate module for any functionality in that you want to split out. I reckon that's as modular as you should ever need to get.
I found a relatively simple solution that uses IIS configuration to simulate areas. No extensions to the existing MVC framework are needed.
Create a new MVC project under your solution for each area you want in your site (ex. Root, Blog, Forum, App1, App2). If you need any common supporting code or a common model, put it in a seperate dll project that the MVC projects depend on.
In IIS, configure the site root to point at the root project directory. Create web applications under the site root that point to each of the sub-area project directories.
When configuring the route maps for each sub area, don't include the name of the application in the route. IIS seems to take care of this for you. (ex. "ShowPost/{postname}", not "/Blog/ShowPost/{postname}")
The benefit is that you can change the name of the web applications independent of the routing system, and each application believes it is running with the whole server to itself.