I have got a project with about 50 controllers and 60 models.
It is quite difficult to work in that mess.
How can I improve that scructure?
Now I am creating namespaces for some logical parts of my application and store them in separate folders. But for models this have got some side effects.
You can organize your classes in subfolders - you don't even need to structure them into submodules (but you can if you want to).
See this other question for details.
Refactoring is a discipline that deals with that kind of problem.
Consider this book.
you can refactor your code using namespace.
Related
I'm building a MVC4 app, I've used EF5 model first, and kept it pretty simple. This isn't going to a huge application, there will only ever be 4 or 5 people on it at once and all users will be authenticated before being able to access any part of the application, it's very simply a place order - dispatcher sees order - dispatcher compeletes order sort of application.
Basically my question is do I need to be worrying about repositories and ViewModels if the size and scope of my application is so small. Any view that is strongly typed to a domain entity is using all of the properties within that entity. I'm using TryOrUpdateModel in my controllers and have read some things saying this can cause a lot of problems, but not a lot of information on exactly what those problems can be. I don't want to use an incredibly complicated pattern for a very simple app.
Hopefully I've given enough detail, if anyone wants to see my code just ask, I'm really at a roadblock here though, and could really use some advice from the community. Thanks so much!
ViewModels: Yes
I only see bad points when passing an EF Entities directly to a view:
You need to do manual whitelisting or blacklisting to prevent over-posting and mass assignment
It becomes very easy to accidentally lazy load extra data from your view, resulting in select N+1 problems
In my personal opinion, a model should closely resembly the information displayed on the view and in most cases (except for basic CRUD stuff), a view contains information from more than one Entity
Repositories: No
The Entity Framework DbContext already is an implementation of the Repository and Unit of Work patterns. If you want everything to be testable, just test against a separate database. If you want to make things loosely coupled, there are ways to do that with EF without using repositories too. To be honest, I really don't understand the popularity of custom repositories.
In my experience, the requirements on a software solution tend to evolve over time well beyond the initial requirement set.
By following architectural best practices now, you will be much better able to accommodate changes to the solution over its entire lifetime.
The Respository pattern and ViewModels are both powerful, and not very difficult or time consuming to implement. I would suggest using them even for small projects.
Yes, you still want to use a repository and view models. Both of these tools allow you to place code in one place instead of all over the place and will save you time. More than likely, it will save you copy paste errors too.
Moreover, having these tools in place will allow you to make expansions to the system easier in the future, instead of having to pour through all of the code which will have poor readability.
Separating your concerns will lead to less code overall, a more efficient system, and smaller controllers / code sections. View models and a repository are not heavily intrusive to implement. It is not like you are going to implement a controller factory or dependency injection.
My colleague told me to separate my controllers in a separate project to make the unit testing as easy as possible, and he also told me to create a solution for the controllers project and test project to avoid loading the whole application when conducting unit testing. Is it a good approach to separate the controllers in a new project?
I am not sure if there is a simple yes or no answer to this question. I would think that your project would have to be very, very large as to have impact on your unit testing. My personal opinion is to leave the controllers in the web project along with the views and view models. However, I am a fan of moving the models to a separate project. My reasons for doing so have less to do with easier unit testing but rather reusing the data access (models) in other applications.
In my opinion you should always at least separate the controllers from your view project (usually a web project for me), because the idea is that the controllers should be able to be used with any view (maybe later you decide to use them for a Windows Forms project, for example). It keeps the namespaces a bit cleaner as well.
From my point of view, making you move out the controllers to a separate project has two things to consider, if you do so, then it enforces you to think how to solve problems with low coupling and precisely low coupled classes can be tested more easily than tight coupled classes.
On the other hand, having the controllers in the same project than the views is kind of logical because the controllers normally know about the views.
If you think of reusability there may be something arguable here because often controllers are "glue" components this means, there is a lot of wiring in them.
This seems like a good idea at first. Creating a prensentation layer in the middle and keeping your MVC project containing only views, making it truly a UI project. On the other hand, you will probably lose the tooling support for the views. Since you have to ignore all the warnings, you have to make sure all views are there, strongly typed to your object.
I don't understand the concern for referencing your MVC project in your test suite since you will probably bring in the MVC namespace anyway.
I am developing my application using Rails. It has 400 or more models and some models contain more than 200 rows just for relationships, so it's too hard handle it. Are there any ways I can handle my application in more proper and easy ways?
In application that I'm working with, there are about 100 models. Few things that helped us develop it:
you can create hierarchical directory structure to models. It is obvious when talking about controllers, but for models it's not that straightforward
you can split models into logical parts by putting chunks of code into modules
doing above two points sometimes allows you to see some ways to refactor your code. Some modules might become common between models. Some things can be excluded into methods that will dynamically generate common parts of models
sometimes modules handle unnecessary logic, and that makes harder to understand them -- if your methods contain lots of cases or ifs to handle different types of objects (like admin/normal user) probably you should use polymorphism
refactor, refactor, refactor ;-)
Wise refactoring takes a lot of time, but if you drop this part of development, project maintenance will become overwhelming. Check out books about Ruby, RoR, refactoring, metaprogramming. Investing time in learning might also bring effects.
it seems like in my model folder, all of my classes fits into one of 3 buckets:
Pure POCO data objects / business Objects
Repository implementation code to query databases and external services
Helper code.
Is this normal and is there a best practices on how to organize this. should i have subfolders for 1, 2 + 3? any recommendations?
If you look at http://www.sharparchitecture.net which tries to provide a best practices framework, you'll see that POCO/entities, repositories and helper code are not only separated, they also exist in different assemblies. This is so that it's physically impossible to leak from one container to another. This framework grew from http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx article which is also good to read.
I don't know if this has been discussed.
Let's say you are in a three developer team. How would you share:
models - views - controllers
by controllers
by use cases
something else?
Maybe someone says this has nothing to do with asp.net mvc but I think it affects somehow.
Do it by story. But by far the best way is have 2 developers work on the same story. Working together across the whole architecture. They can share the tasks as they are needed, creating the view or the model or the stored procs, and tables etc. There will be some stepping on toes but at those times they can pair program.
Try to think of the 'team' doing a story. Rather than a single developer, and if they all work on the same story at the same time, the development should flow at a cracking pace.
As Kieron says, you need a ten minute design meeting with the whole team, to decide how its going to hang together.
We break it up like this:
Team A:
Views
CSS
JavaScript
Team B:
Controllers
Models
Database
We use Mind Mapping applications to work out what Controllers and Views we need first, so the whole team knows how to tie things together.
It's worked brilliantly for us, increased our productivity substantionally.
By use case or task. Helps spread the knowledge about the entire process around.