asp.net MVC Solution/Project layouts [closed] - asp.net

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
This is more of an open question rather than looking for one specific answer.
As we all know there is no one answer that fits all solutions but I am curious to find out how you structure you asp.net MVC solutions and any pitfalls you may have come across in your design or things that you would do differently if you could start again.
The standard asp.net MVC template is just a basic template and I'm sure I've read/heard in a podcast that Scott Hanselman stated the only reason the Model folder is there is so people didn't ask where's the model. This already implies that maybe it should be moved to its own separate class.
Personally in the small MVC apps I've done I've separated out the model into its only class that holds the model and the repository while the 'MVC' project has the controller and the views. This has generally workout without any issues but as I said these have only been small apps.
So what are most people doing?
- Just using the standard template?
- Separating out just the model?
- Separating out the model and the controller?
- Separating out even move so all the data access is done through web services or some sort of data portal?
- Or something totally different?
Finally how are people creating unit tests? Just one unit test class that test each of the projects or a unit test class for each project?

Personally I use Jimmy Bogard's approach: Organizing ASP.NET MVC solutions.

To be honest, most of the time I have found the standard template tidy enough for me to simply re-use it. I would say its really just down to your own particular organizing preferences.
If my model got really large I would definitely consider creating a separate class library project for it.

Related

How to handle training on a specific technology in Scrum? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
My team is making the transition to Scrum.
I am facing an issue I still not found on the various Scrum resources I've been studying: how to manage training?
I express myself by example:
my team has 4 developers, 2 of them know nothing about Test Driven Development
the project must be done using TDD
Should I create a backlog item "Study TDD" and use the first sprints so that the untrained developers learn TDD?
Or should I remove the developers from the project until they completed the training? Which is the best practice in this case?
Just send them to the training, and continue your sprints as normal. While they are in training they won't contribute to the velocity, the same as if they were sick or on vacation or just having a bad day. The velocity isn't a goal so much it's an indicator.
You can create a story for training if you want, but it isn't necessary. If creating the story helps, by all means do it. Don't do it just because you think you're supposed to. I've been on teams that liked to track non-product tasks, and teams that didn't. Do what your team decides to do.
In your question you wrote:
the project must be done using TDD
I hope that's because the team decided that, and it wasn't something that was decided for them. The whole point of scrum is to build a team that can make these decisions for themselves.
Well, I will answer YES.
you need to create back log
you need to define test cases and follow TDD
you need to do stand-up meetings and daily follow up
you need to define a team member as scrum master who have best understanding
further, you can engage an online training of transformation expert
Like, I know these guys regarding Agile/Scrum Transformation. http://sparklegenius.com/solutions/agile-transformation/

Which steps should be followed to integrate two different software process models to each other? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
Recently, I am working on my course project, the topic is the creation of a new hybrid software process model by integrating Scrum and Team Software Process (TSP). Integration of these two models will be based on the SEMAT Essence Kernel Framework.
I am wondering:
Which steps should be followed for this integration (like
determination of the roles and artifacts in these two models)?
What should be the criteria to decide on good sides?
Thanks in advance!
The best way I think I can answer this question is by quoting the agile manifesto.
"Individuals and interactions over processes and tools"
Agile is about people, teamwork and craftsmanship. It's about involving the customer closely to figure out what really is needed - and delivering that, in small increments of working software. Agile is inspect and adapt, based on experimental delivery and the feedback and evidence that comes from that.
Trust yourself. Work closely together and you can do this. The best learning often comes from doing. :)

Spring MVC - Project structure - best practices [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What's the best approach?
1- Create multiple projects:
2- Create a single project:
I'd suggest you take a look at Spring's Project Sagan. It's the source code for their current website (http://spring.io). While they used a multi-module approach, it wasn't divided as you are suggesting. They really just pulled out some client work and kept the rest in a single module.
This site was written by the Spring team the way they would use their own tools and released as a reference application to answer questions just like this. I encourage you to take a look here: https://github.com/spring-io/sagan.
The point is to ask yourself what is the point in separation. If you are planning to run them in different containers on different servers, then it makes sense. If it is a large project, it makes sense to separate.

Modularization of PL/SQL packages [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Currently I am doing a restructuring project mainly on the Oracle PL/SQL packages in our company. It involves working on many of the core packages of our company. We never had documentation for the back end work done so far and the intention of this project is to create a new set of APIs based on the current logic in a structured way along with avoiding all unwanted logic that currently exists in the system.
We are also making a new module currently for the main business of the organization that would work based on these newly created back-end APIs.
As I started of this project, I found out that most of the wrapper APIs had around more than 8000 lines of code. I managed to covert this code into many single APIs and invoked them from the wrapper API.
This activity in itself has been a time-consuming process but I was able to cut down the number of lines of code to just 900 in the wrapper API by calling independent APIs for each business functionality.
I would like to know from you experts if this mode of modularizing the code is good and worth the time invested in it as I am not sure if it would have many performance benefits.
But from a code readability perspective, this is definitely helping and now I am able to understand the 8000 lines of code much better after restructuring and I am sure the other developers in my organization too will understand.
Requesting you to let me know if I am doing the right thing and if its having its advantages apart from readability please do mention them. Sorry for the long explanation.
And is it okay having more than 1000 lines of code in a wrapper API.
Easy to debug
Easy to update
Easy to Modify/maintain
Less change proneness due to low coupling.
Increases reuse if the modules are made generic
Can identify unused code easily

Devepole a journal system with Drupal [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am going to develop a journal system which has paper submission and review actions with evalution forms,something like OJS system. I want to use drupal for it but I am not sure if it is a good choice.
Does Drupal have ability to create such applications ?
It is a very generic question. To answer some part:
Drupal can be customized and used for a lot of projects, thanks to the powerful community and module developers.
Let me give a glimpse of possibilities, you can find the rest:
Each paper can be a content type. Each user can have specific roles and permissions (eg. publisher, editor, reviewer etc) who are allowed to do specifically what you allow them to do. They can apply for higher roles as well.
Each review process can be captured and maintained using workflow module. There are plenty of tutorials for that.
List of articles can be shown with various properties and filters using views. They can be shown in various regions of a theme you select or make of your own (or customize).
The community can be built using forums.
In short there are thousands of possible ways you can make this. But one note from personal experience: sometimes you will find extremely tough things to be done in simple ways, while simple things will take time. This is mostly because like all systems, it takes a bit of time to get used to with the drupal api.
Best of luck!

Resources