I'm tired of looking after a frame work for mvc implementation.
i want to build a good MVC based structure of my own that will serve me in my projects.
so here is my thinking I'd like to know what do you think.
first of all. here is the folder structure:
The folder structure
the Admin and the Site folders:
I assume that the controllers/views in the admin/site and are totally different one from each other,
so it is necessary that they will be in independent in each folder.
if the autoload in the admin or site folder will not find a view/controller in its folder he will look for it in the MVC folder
the model, which is the db layer can be inside the MVC folder because it is shared to the entire project.
a function like get_article_by_id can be used in the site and in the admin as well.
the MVC folder:
will hold the entire project models. and shared controllers/views.
the classes folder:
will be use as a framework folder, it will hold classes such as mailer,db that will implement php functions
How does that sound to you?
Part of the benefit of using a popular framework is that other people know it and can help you with it. If you write your own, only you know about it. There is an MVC framework in almost every language and lots of thought has gone into each one, which means you get the benefit of a lot of experience by selecting an existing one, rather than writing your own.
As long as you feel convenient with this structure - use it.
If you need to ask advice about whether your reinvention of the wheel is any good then it's probably not better then the wheels already in existence.
A wheel inventor that knows he has a better wheel wont need to ask advice.
Related
In most of the MVC / MV* type frameworks I've played with they want you to have your source organized something like this:
model/
FooModel.xyz
BarModel.xyz
view/
FooView.xyz
BarView.xyz
controller/
FooController.xyz
BarController.xyz
organizing into directories based on the MVC elements rather than by the applications object types. Some part of me always feels like life would be easier if the code was organized like so:
Foo/
FooModel.xyz
FooView.xyz
FooController.xyz
Bar/
BarModel.xyz
BarView.xyz
BarController.xyz
Because in general, if I'm working on Foo (adding a new field for instance), I am often opening up all the Foo* files, which is tedious (first world problems) because all the Foo files are in different directories.
Is that a code smell that there is too tight of coupling between the Foo sources?
And of course, this alternative gets less appealing when we have models, views or controllers that don't have corresponding views, controllers and models. Which is often (usually?) the case...
So why is the standard organization for MV* frameworks actually better than my proposed straw man alternative?
I've been in the same dilemma myself. Looking in StackOverflow, What strategy do you use for package naming in Java projects and why? have some interesting insights, specially Uncle Bob's design principles for granularity. In the Common Reuse Principle he says:
THE CLASSES IN A PACKAGE ARE REUSED TOGETHER. IF YOU REUSE ONE OF THE
CLASSES IN A PACKAGE, YOU REUSE THEM ALL.
In the design package you mention, it makes perfect sense to have a model package, as is very common to reuse several Model classes through Controller and View Layers. On the other side, foo package can be hardly reused as is an application module itself. Also, according to the Common Closure Principle:
THE CLASSES IN A PACKAGE SHOULD BE CLOSED TOGETHER AGAINST THE SAME
KINDS OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL THE
CLASSES IN THAT PACKAGE.
Several technlogy-related changes -like changing the JavaScript Library or the Dependency Injection Framework- will have minimum impact in model-view-controller packages (only one package should change) than in functional ones (the changes will span in all packages).
Not sure about other MVC frameworks, but for ASP.NET MVC specifically, the views should be in the Views/ folder.
One of the principles behind ASP.NET MVC is Convention over configuation. The view engine expects to find the views in a certain location. I believe you can override that, but it's generally better not to. (Use the convention)
I think the biggest problem with this file organization is cascading changes. If I need to add a field, I need to update 5 places (the model, the view, the viewmodel, the controller, the unit test). If you're digging around in folder trees to find these things, it can be tedious.
Maybe the question behind the question is 'How can I navigate through my solution artifacts more efficiently?' Again not sure about other IDE's, but since I use Visual Studio I've got my own set of preferences to help with that task.
In Visual Studio ctrl+, (control comma) is great for navigating to types/files/artifacts within a solution. Also I use F12 and Shift+F12 for 'goto definition' and 'find all references'. Also I customized the 'Find in Files' button to display image and text in the toolbar to make the button easier to hit.
I want to ensure I follow best practices in the context of ASP .NET MVC 3. I am using the Razor template engine to generate automated e-mails when certain actions are performed on an MVC 3 web application.
I have created a separate class library for the e-mailer and this class library will contain the models that will be used when generating the emails as well as a message factory which will generate the necessary message text using the appropriate view and model.
I am unsure as to where I should be storing my view templates. I would like to store them as CSHTML, as this will allow the developers on the project (who are new to Razor) to use IntelliSense while creating the mail templates.
I don't think I can store them in a folder in the class library as this will make deployment more complicated. If I store them in a folder within the MVC 3 Web Application root, they will be accessible to anyone on the internet with knowledge of the correct path. I now consider two options:
Store them in the app_data folder, but this seems untidy.
Store them in a folder called "EmailTemplates" within the Views folder in MVC. I think this is the best option as you can not browse to it directly (no controller) and our developers can access them easily and make use of IntelliSense.
Is option 2 the best option, would it be a sin to have these mail templates located here? I would then access the files directly through the local filesystem but I am not sure if I will have security issues once deployed to production (perhaps using the app_data folder would prevent this). I would like minimal configuration for deployment.
Thanks!
As usual, there's no one right answer, its all about philosophy and approach, but most important (in my mind) - utility. I.E. if it works, easy to maintain, understandable - why not do it?
I would, in your shoes, put it under App_Data folder - this is by definition where all data that application uses goes. Database is there, configuration XMLs are there etc. So why not use that folder for your purpose.
You can easily access it like this from within your C# code: System.Web.HttpContext.Current.Server.MapPath(#"~/App_Data"). I don't think any other (created by yourself) folder will be any better or worse ... its just App_Data is there specifically for these purposes, but it doesn't mean you cannot do something else, that makes sense in your application.
Hope this helps.
After doing more research and some experimenting, the Views folder seems to be the best place for my email templates. Here's my reasoning:
The email templates will only be used by the web application and nothing else.
The application pool the MVC application will run under, will at the very least have access to read the folders within the Views folder. This means I don't need to cater for any special permissions for folders during deployment. (Although this is true of the App_Data folder as well).
IntelliSense does not work from within the App_Data folder but does work within the Views folder. As the developers on this project are new to Razor, IntelliSense will make things easier for them. Also just makes development of the templates easier.
Although I created a separate project for the template mailer, one
can store the models for the mail templates with your MVC models as
well.
I have a question about organizing .resx files in mvc3 application. So far I have managed to do the following:
Creating new class library in a solution for resources and adding resources for two languages. Everything works fine when I have for example:
Resources.resx //default language
Resources.en.resx //english language
But I want to have such organization in my class library:
DefaultLanguage foder
- Resources.resx
en folder
- Resources.en.resx
I want to organize resources by folders. I think it is more appropriate for people who will translate the site and it is also more maintainable. When I organize resources in such a way the web page returns an error...cannot find error. Am I missing something? I know that you should not have folder name in namespace because that would mean that referencing resource in View is dependent on folder name and this is not correct.
The point is I would like to have the same behaviour of resources wheter they are organized in folders or not...
By the way: I check on the web and could not find any appropriate solution.
Thank you for your answers!
MVC3 uses ASP.NET resource management. See ASP.NET documentation for details. If you want to rely on ASP.NET behaviour and generated strongly typed classes, then you must keep resource file from default language and other language specific resource files together.
To have the same tree structure that you suggested, then you have to implement your own resource management. You probably don't want to do that, because (at least some) resource editing tools rely on that behaviour.
On our projects we have one resource (and his translations) for each view. They are in folder Localization within MVC3 project. Inside we keep the same tree structure as is within Views folder. This is more or less the same as ASP.NET local resources are organized. Common strings are kept in one .resx file on root of Localization folder. This ensures maintainability.
To keep your people that will do translation happy you have to pick good .resx editing tool.
Right now, I’m working on a legacy web application that is made up of multiple screens, each one performing a separate function. I’m in the process of converting several of the screens to EXTJS 4 using the MVC approach. In order to isolate the impact of my changes and because we don’t have time to convert the entire app at once, I’ve converted two of the screens into two separate EXTJS 4 apps. Each screen now has its own folder in which I’ve set up an app using the appropriate file structure and app.js file.
My question is this: as I continue developing, I may want to use models from one app (screen) in another app. How do you share models, views and controllers between applications? What’s the best approach?
FYI, I’m using autoloading to pull everything in.
Thanks
I would not use autoload in production, because it generates to many HTTP requests to get all files, which slows down the page load speed. This is well documented at Google's Page Speed and Yahoo's Best Practices for Speeding Up Your Web Site.
The best practice is to preprocess the resources upon deployment of the application and generate a single javascript file with everything in it that is sent in a single (GZIP) compressed response. There are several tools for this job, but it depends heavily on your toolchain. You can for example have a look a the SO question Best JavaScript compressor to get recommendations for various compressors (I use Jammit).
When you have a flexible configurable JavaScript compressor in your toolchain, you can set up a shared folder where you have your common files, like model, stores and some libs. These are now included in the builds for the different projects.
In case you have a good reason to serve single javascript files, you can either use a good version controll system like git and make use of submodules. Which this approach you'll have a separate repository for common files. This gives you the downside of slower page speed and a little overhead with updating the submodules.
As last solution, you can use a symbolic link on the file system to link the common folder to the different other projects.
Here's what Saki said to me on the Sencha Forums:
The multiple applications on one page, or sub-applications of Ext MVC
are not supported yet, however, developers are working on this
functionality, AFAIK. Such implementation would most likely solve also
the problem of re-using models, views and controllers among (sub)
applications, I hope.
More specifically regarding linking multiple applications:
I would just soft-link files of MVC components is this case. There's
no logical or functional connection among them now, only I wanna reuse
already written file, right?
I seem having difficulty in understanding the reason behind the need of having many projects inside one solution (in my case visual studio 2010 with c#).
The only use that comes to mind is if I am creating a new classes I can test them in a console application first, then add another project to the solution to use these classes with the project that I want.
kindly guide me to the correct way, thanks.
A typical project might have a UI, a data layer, a services layer, and a domain layer, as well as some tests. A typical arrangement would be for each of these to exist as their own project file. The solution would contain all of these projects so that you can make modifications and debug different parts of the app at once.
If you're just starting out, you probably cram all of this stuff into one project. That's fine for learning, but is an absolute mess for maintainability and reusability.
There are 3 main reasons that immediately come to mind for splitting your solution into multiple projects: Reuse, Encapsulation, and Project-specific settings.
Reuse
You may have a Utilities project that is shared between more than one solution. You may also have data access and business rules that are defined in class libraries, but are shared between multiple UI projects, such as having a business application that has a web interface, a desktop interface, and web services. They all need to share the same logic and data model, so you wouldn't want to replicate it in each solution separately.
Encapsulation
Another reason is to achieve encapsulation, one of the main principles of OOP. Your classes may have internal methods and properties (or the classes themselves may even be defined as internal), which makes them only visible to other classes in the same project. If it's there to achieve a specific purpose but not something that should be accessible to all, by splitting your classes across separate projects you can make those properties, methods, and classes visible to your classes, but hidden outside the scope of your project.
Project-specific settings
There are certain project types that behave completely differently from one another. A Web Project is different from a Windows Forms app, which is completely different than a WPF app. This kind of goes along with #1 and trying to achieve code reuse; since you can't have a single project that is a website AND a Windows Forms app AND a WPF app, you create each UI as its own project and put as much logic as possible into a separate project that can be shared between all of the UI projects.
A couple possible reasons off the top of my head:
a project may be useful in more than one solution
simple organization utility - just like you might have classes in separate files even though a single source file can hold multiple classes just fine.