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 9 years ago.
Improve this question
I am starting new medium size ASP.Net MVC project. There will be 50-60 tables. IE: employee tables(assigning training etc/) , basic warehouse management,. There wont be complicated workflows also.
I am looking for the ways to reduce my development time.
Scaffolding is a good starting point but hard to manage.
I could not decide about using AngularJS SPA or not, Using angular JS reduce the development time ? Or what is the advangates of using angular ?
What is your recommandations about reducing the development time on ASP.Net MVC projects, which ways are you using to building medium size applications.
I don't know your experience with MVC, but generally speaking, I'd suggest to use a UI Framework (like Telerik, DevExpress or Aspnetawesome) because they offer plenty of example on how to organize your project. It definitly saves you time. Then which one you choose depends on your preference and budget. All 3 are good.
As for managing your data, just create a Domain project which will only contain your data access (probably repositories). For that project, it is no different from a normal C# project. You'll probably want to use Entity Framework, nHibernate or a similar ORM.
So to recap, divide your solution in at least 2 projects, one for the data and one for the UI, then use a UI framework for the MVC project and an ORM for the data access.
As for AngularJS, I would not focus on such tool unless you are really comfortable with MVC.
Pros:
On the long term, you may save some time
It is free
It is well supported and seems to be there to last
Cons:
If you are part (now or eventually) of a team, not all members will
know that tool
If you are comfortable with MVC, this will not save you significant time in my opinion. You don't become an MVC superstar
because of it
If you are not that comfortable with MVC, incorporating such tool is a bad idea. It is better to know a few tools but to use them
properly than to poorly use many of them.
Related
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 6 years ago.
Improve this question
In either .NET MVC 5 or a .NET Core MVC application, is it possible to split your Models into a Data Transport Layer, your business logic into a Business Logic Layer and your Db Contexts into a Data Access Layer? I essentially would want the main project to really only have controllers that call to the BLL, and display the results in the view. That way there is portability with my application if I wanted to exchange the main project, which is essentially just a presentation layer.
I know I am going to be needing this kind of architecture as I am building an application that will share a lot of the same business logic between the two applications. What ways can I still get access to helpful features like scaffolding a model into views/controller, and still maintain that portability? Is there a way to do such a thing?
Please note, that this project may be on a short budget, so it is pretty essential to be able to maintain the scaffolding tooling.
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 6 years ago.
Improve this question
In most ASP.NET Mvc tutorials, you see people creating simple models and then scaffolding controllers with views, using Entity Framework.
In most tutorials you will also see that they create a new DbContext class which will have the DbSets. I understand that this is a good thing to do for educational purpose, to help the person understand how it works.
But the account system that comes with a default Mvc project always links to "DefaultConnection".
Some tutorials will also make use of the account system to advance further, but that means that at this point you would have 2 databases running to support your web app.
one for the account info
one for the details of your model(s)
Is this the correct way to work? or do most developers/companies just use 1 database for both of these?
My reason for asking is because i found this tutorial which uses both of these aspects and works on 1 database and it is the first time i see this being done.
There's no right or wrong way. You need to evaluate the requirements and time lines for your projects and decide which options suits you best.From personal experience, in all the projects I worked on, the account info and the models reside on the same database.
Remember that if you have two databases you will need to create two data contexts to access them.If the database needs to be moved to another server, you would need to move two databases and change the connection string in two places, also the maintainance and upkeep on the DB would need to be performed in two different places.It's really a maintainance headache and should be avoided in my opinion unless your requirements have some compelling reason that you should place account info into a separate DB.
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
These days my friends recommend me to use ASP.NET MVC, instead of ASP.Net Web-forms.
But I'm not Optimist to it.
I consulate about this problem and my friends said me that these two technologies have their own place in web programming zone, according to the project type.
Now I want to know what type of projects are better to be developed by ASP.Net MVC?
and the 2nd question, In your opinion is it conceivable that Microsoft abandon this technology?
Nowadays i always use mvc for all my new projects it is much more cleaner code. And you dont have to rely on asp.net web controls i dont think web controls render nice html.
Plus that you dont have to think about viewstates.
ASP.NET mvc can apply on all type of projects it is more the way how you like too code then which type of project. Thats my opionen.
I doubt very much it will be abandoned any time soon.
MVC is a different way of working and probably more suited to a kind of developer as well as a kind of project. It gives better control over your markup and front end code, forces better practice for separation of concerns and hands over a lot more power over how the site works.
This is a broad subject and better suited to https://softwareengineering.stackexchange.com/
If you rely a lot on the ASP.NET Web Controls then you may find MVC difficult to get to grips with at first.
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 9 years ago.
Improve this question
You can find thousands of questions out there about how you develop software and which methodology is the best one. But mainly these are targeting medium to large teams, with people having different roles and responsibilities.
What I'm interested in is what methodology are you using for your one-man-shows? What steps are you doing, what documents are you creating to get the things you want to develop clear and document it well, to share it with the community?
Especially, I’m interested in the following questions:
_Are you using a structured approach even you’re developing on your own or no at all?
_What phases are you using?
_Which documents are you writing before and after coding?
And if you have “your” standardized approach, can you share templates which you are using?
Thanks in advance,
cheers
Gerry
Personally I think it is a matter of making decisions when it comes to the development process (solo). In my case I wouldn't recommend setting up a massive development process but I would pick elements which prevent problems that I have earlier had. My approach for small applications (in the right order):
Always write down what you are going to make and what you are not going to make (define a scope) - Think of functional requirements (Functional Design)
(OO only) Make a class diagram that displays relations between classes. (Technical Design - Sequence diagrams, while usefull, take up massive amounts of time to make)
Write your program according to what you have just written down (or part of it).
Refactor and redesign your application (once in every X hours, write this one down)
Repeat step 3 to 4 until the result is what you wrote in the Functional Design.
Walk through every corner of your application to find every single path and write this down in a testdocument. Identify possible problems in the paths and test them.
When it comes to big applications however (or assignments for someone else) I prefer using the "medium to large teams" approach. Which almost brings a guarantee that you will not be meeting most problems.
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 9 years ago.
Improve this question
As a C++ developer from the 90s during the great OOP wars, I put high value to OOP as a basis for hiring new C# developers into the company.
However, there are plenty of frameworks today like ASP.NET MVC that handles most of the OOP heavy lifting. Programmers without deep knowledge of OOP can just as easily follow the paradigm and still be able to complete their projects. OOP may not be as compelling as it was before for us application developers, especially with a framework like MVC.
I can see a few instance where OOP will be really handy, like for example developing a workflow type of a project. Or those with state-machine requirements. But really, most projects that really come by (at least to us here anyway) are just CRUD functionalities.
Below is my list when hiring. Is it fair to have OOP there as the number one item?
OOP and Design
Server side programming: C#, ASP.NET MVC and EF
Client side programming: JQuery, CSS, HTML, etc.
Database design
OOP-thinking indicates, that candidate is good at project-architecture. You always need to implement some reusable components, classes, functions, and of course libraries. From my point of view, it is must have for any candidate to know OOP and Design Patterns to be hired.