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.
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
After a lot of reading i still unable to understand the difference between the design pattern MVC and 3-tier architecture.
I see that the model in mvc is the same as business layer in 3-tier.
In all websites i searched in, i found that MVC is an applicatif architecture for presentation layer in 3-tier architecture.
I guess in a sense a MVC project could be considered a 3-tiered application. It has a data layer, view layer and a logic layer. However, all 3 of these layers are tightly coupled to the MVC project.
On the otherhand an n-tiered application may consist of a UI application(ie. MVC web app) which calls a web service(ie. WCF) which then calls a Business Logic/Data Access layer(ie. LINQ-> SQL, Database calls).
The main difference I see is MVC is tightly coupled to it's architecture. By this I mean, you can not just remove the controller/models without rebuilding the application. N-tiered applications on the other hand are more loosely coupled. Meaning, I could switch out the WCF layer for Web API and the rest of my application would not care. This is an advantage where growth/expansion may required.
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.
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
We have 2 developers that are working on 8 applications. Should I split them in separate projects or keep all in one project? If i should split them, than how can I work with aggregated agile board? Keeping separate agile boards is not very useful because since there will be much more agile boards then developers.
My personal preference is to keep TFS projects for a group of related applications. For example, if you have a website, an app, a webservice, and a scheduled task all working on essentially the same data but for different scenarios, I would group those as a single TFS project.
However, if two applications are fundamentally different they should be segregated from each other. For example, one is a mobile eCommerce application, another is a video game about elephants fighting zombies armed only with a canoe paddle.
That way, the task board makes sense from a logical perspective. With related applications, you'll have stories that cut across all of the projects. You may have a common data layer service, or perhaps they all use a common engine that you want to be able to maintain on the same cadence.
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
First of all, this is my first week on MVC 4
Microsoft claims the MVC will be the best web coding solution in the future based on three level framework.
1.Yet in their MVC concept, view and model can talk without controller, can any body tell me why they made that like a circle? What's the benefit behind it?
2.Without the view_state in web form, how can I know if a page is a post back?
Any open-mind ideas are welcomed!
1.Yet in their MVC concept, view and model can talk without controller, can any body tell me why they made that like a circle?
What's the benefit behind it?
View and Model cannot talk without controller. Your view would never have known the Model if the Controller hasn't passed it to.
2.Without the view_state in web form, how can I know if a page is a post back?
Why would you even want to know such thing? This is an artificial concept invented specifically for classic WebForms to alleviate the stateless nature of the HTTP protocol and make Web development ressemble Desktop development. In an MVC application you never need to know anything like that.
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 4 years ago.
Improve this question
I have started to doubt my initial design decision, as everywhere I look I find tutorials on MVC where they just dump the access layer right into the MVC project. (Which goes against everything I've learned)
BarRepo: Handles access to an API.
FooRepo: Handles access to my Database (using EF).
FooBarHandler: Joins data from the two repos into useful data for the controller.
Controller: A controller, nothing speical.
As you can see in the picture, I've split up each part into their own project and try to obtain loose coupling. So I don't send Entity Framework classes out of the database layer and so on. However I've run into a bit of a pickle. The data amount fetched have become so large that it's noticeable on the frontend, so I needed to introduce paging. So I followed this tutorial.
My "problem" is that now MVC, Logic and the Database projects are depended on PagedList, so things aren't so neat and shiny anymore.
So my question is what would you have done?
You don't need to use PagedList as you can create a paged list of items yourself. Take a look at this StackOverflow question for an example of how to do this.
To summarise:
var pageNum = 3;
var pageSize = 20;
var pagedItems = data.Skip((pageNum - 1) * pageSize).Take(pageSize).ToList();
That way you will have no dependancies on PagedList, which will help reduce the coupling in your design.