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 a project in asp.net. I want to use 3 layer architecture. now I have problem with layers. I manage these layers like this:
but I have seen somewhere that uses App_Code and some other formats. could you please help me which one is true and standard?
App_Code is a special ASP.NET folder which is used by ASP.NET Websites. It is not used by precompiled ASP.NET applications. You can read more about the differences between the two in this article. So if UI is an ASP.NET Website you could use the App_Code folder to put some logic although this is better suited to external libraries as you have in your current design. This allows for better unit testability of this code and reusability.
Avoid the use of App_Code. Anything you put in here doesn't compile until the site is executed. Any dependency that your forms and user controls have is best put into your UI layer, outside of the main web folder. You'll have a lot more peace with objects that are compiled early rather than later.
Now-a-days I see this standard a lot:
ProjectName
-ProjectName.Core (All poco classes and interfaces)
-ProjectName.Data (All entity framework stuff)
-ProjectName.Service (All business logic)
-ProjectName.Web (All font end logic)
"Core" is reference in all projects to move data around.
"Data" is referenced only in "Service".
"Service" is referenced only in "Web".
Related
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 months ago.
Improve this question
So, I am using a classic MVC architecture with a service layer for my ASP.NET core app.
I added an Admin area and in it I added Controllers, Models and Views folders, so I can easily separate the admin-related stuff from the general user-related stuff. Now I have two options:
Creating a Services folder in my Admin area and literaly copy-pasting the already created services, but from my general Services folder
Directly using the already created services from the general Services folder
I am not sure which approach is generally accepted as better, so I hope for some guidance.
If you can use it as is, then the general Service folder is enough, but if you need to change/add many things than it is a good idea to create a separate service. (You can still use the general Service as a dependency in your admin service)
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 just found about the ASP.NET boilerplate framework for ASP.NET Core applications. The boilerplate is cool, it has all the necessary structure we need in order to create a SOLID proof web application.
My question is that, as per the site I have to create entity models in .Core project, and Dto's in Application project but as I can see these Question, and Answers are different entities but they kept both of them in the same folder and same namespace.
It does not look like a good practice, can anyone tell me is it wrong to keep these related entities in the same namespace/folder or it's ok to do so?
You can locate entities/services into any namespace. This is not related to the framework actually.
Question/Answer application is very simple project where there are just 2 entities. I thought that Question is aggregate root and answer is a child entity (they are a single aggregate together). This is why I put them into same namespace.
I suggest to follow "namespace per aggregate" principle, but "namespace per entity" is also fine.
BTW, #Dongdone, AspNet Boilerplate is completely open source & free. We have a another product, AspNet Zero (https://aspnetzero.com) that is commerical and developed on top of the ABP framework. But that does not make the ABP framework a paid tool. It's absolutely open source & free.
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 7 years ago.
Improve this question
I have an Asp.net MVC project that includes three management systems:
1.Car rental system
2.Bus ticketing system
3.Home delivery system
Each system should have different types of modules and each module deserves an area of its own.How should i manage the project. Should I create three different projects for
car rental,bus ticketing, home delivery system and create nested area to manage their own modules.I also want to maintain generic repository pattern,unit testing.
For asp.net MVC you can create one core MVC project that include (add reference) in other project that project contain your Car, Bus and Home areas.
You can create a main web project for your application with three areas for three modules.
And you can create three class libraries for three different businesses.
So, if you need to change any business logic, you just go to the particular dll and made changes. (ex. go to MyWebApp.Service.Car and update and compile the dll and update this dll to your production site to update the business logic for the car rental system)
Please feel free to ask any doubts on this...
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
My MVC's controller actions are getting huge. I want to create a service layer so that I can move code there. The idea is to use the SOLID principle: the controllers use the service layer to get the domain models that will be then transformed into view models.
My question is simple: Should my service layer be a new assembly (project) that will go along with my MVC project or should it be simply a class inside my already existing assembly (MVC Project)?
My approach will be similar to the following one, but unfortunately the post doesn't explain exactly how was the service layer defined:
http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx
I would consider making the service layer a separate thing.
Service can be an interface-based object that is implemented either in-memory in the application or distributed and accessed remotely via SOAP, REST, RCP-XML, or anything else. The controller/client need not know or care if they have a client program that's interface based as well.
A dependency injection, interface based solution would allow you to inject client and service implementations in pairs so controllers need not be disturbed if you change how to access the services.
Controller is usually closely tied to a view. Views come and go, but services tend to remain. Services should map to business functionality that could be shared across applications.
Should my service layer be a new assembly (project)
Yes, it should. Other UIs might want to use it in the future...
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 creating a asp.net mvc2 project which contains multiple modules in the project.I am thinking to create supprate controller for each module, but i want to know what are the advantages & disadvantages out of it?
Seperate controllers means a Seperation of Concerns, you would have separate controllers to handle logic that should be separated. So you won't get a cluttered controller handling everything in your application. Besides clarity in your application, this brings the benefit that if you need to change one thing, you don't break other code handling other logic in the same place.
Naturally this separation is also present in your Views folder, so you'd have clear oversight what's going on where in your app.
Also, if you have a lot of dependencies that your one controller needs (like services getting different domain models) you would have these listed in one place, which would make it less clear what the primarily function of that controller is. It's nicer to have more controllers with less dependencies each.
Another benefit is that you get user friendly Urls without much effort:
www.domain.com\home\index
Pretty much spells out this is the homepage.
And:
www.domain.com\account\login
does so too.
Basically, make objects (controllers) for each "section" of your web app, like you would make objects for each functionality of the business logic.
i would read this article: Biggest advantage to using ASP.Net MVC vs web forms
since it already covered your question for a big part.