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 7 years ago.
Improve this question
I am working on a asp.net mvc project. Also I want to use n-layer solution structure. So, I am using the following structure for my solution. It shows specially the part of the solution I have doubts with. I am planing to create interfaces for each entity I need in order to not repeating code and not have problems when passing data (lists or objects) from dal to presentation. What do you think? Is that a good approach?
[
I think you're missing the point of what MVC is. It effectively handles your layers. Using a BAL and DAL is N tier application. If you were using a real MVC project these layers are meaningless.
It's better to work with Generic repository pattern. LINK
You should create a Domain layer which will be the core of your project, in there you put your entities, your interfaces for entities, repositories and services, and this layer do not references any other layer. It makes your architecture more flexible, for example, if you work with NHibernate, but needs to change to EF, you just create a Class Library, and implements the repository interfaces that is in Domain layer, and the other layers not need any change.
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 2 years ago.
Improve this question
I'm building a C# WPF app that will use IBM iSeries data for starters but will use oracle data via web service later. In order to switch between them (and support testing) we create interfaces and program the view to interface, right? Each of the data sources would be responsible for mapping to a common DTO structure used in the view model.
So if these two data sources that implement the interfaces are in separate projects, where are the interfaces defined? I'm thinking about how to define the interfaces so I don't have to keep up separate versions in the respective data source projects. If I create the interfaces in the view then it would create circular reference, the data source needing the view for the interfaces and the view needing the data source for dependency injection.
Please forgive me for the rather generic question. I'm not asking "how do I structure my app", it's more of how do I solve the specific issue of the mechanics of the interfaces.
Thanks, Mike
Put them in a separate project. Add a reference to that project wherever you want to use 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 2 years ago.
Improve this question
I can't wrap my head around what to choose between these 2 flows, in these diagrams I'm using mediator pattern but it does apply to any use-case that has a layer for an interface ( API ) and the application itself ( Domain ).
Should I enforce DRY and return the response from the domain directly to the client. But add a separate DTO for incoming requests that is processed by the interface and map it as a domain model.
Should I enforce SOC and map all objects coming in and coming out of the domain. One of my major pain points is that adding a new property would require me to update all my objects both on webapi and domain.
I'm curious around what the community currently practices around DTOs on a layered architecture, I've been searching both here and in github repos and most implementations follow the first one ( albeit those were only "sample" projects )
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 5 years ago.
Improve this question
I didn't find any good answers regarding of 3 tier architecture using ASP.NET MVC and Entity Framework (database-first).
I know in UI layer will be an ASP.NET MVC project.
Where will be Entity Framework?
What will be in DA layer?
What will be in BL layer?
You can organize your MVC project architecture separating your DAL, BL and Presentation logic creating three different projects, naming each of them, for example, with suffix DAL, BL and Web. The first two projects will be class libraries, the Web will be an mvc application.
EntityFramework goes obviusly in the DAL project. Then, all your domain model logic will goes in the BL project.
Finally, your Web/Presentation project will implements all controllers, that invoke domain services in the BL and manage views through view models components and dto objects to/from BL (your Model objects).
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
In C# commonly use DTO classes for data transfer. But also we can transfer data using Entity Framework generated class. But most of the time we uses DTOs to transfer data. Why DTOs needs to pass data across layers instead of using Entity Framework generated classes.
I think one reason, using dto classes does not directly bind the client to your database model, as it would if you were transferring ef classes. It allows you to make changes to your backend and in some cases keep these changes from effecting your clients. There are truly many more reasons, I think doing some research on the net will help more perhaps, there are many fantastic articles. However you will have to decide whether the use of dto classes fit into your current project. Some people say dto classes are bad and they go in depth to explain why they say so, others say the opposite and again explain why they say so. You will need to determine which is best for the task at hand. Overall I think answers for this question would be opinion dependant. Personally, I love dto classes.
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
During the Tailspin Spyworks tutorial (link below) the author adds a partial class for implementing some business logic. When doing this he states that this approach shouldn't really be used in a live project and that you should implement a Business Logic Layer instead.
What approaches would you suggest for this when using entity framework and asp.net webforms?
http://www.asp.net/web-forms/tutorials/tailspin-spyworks-part-5
http://tailspinspyworks.codeplex.com/releases/view/44512#DownloadId=119611 - download source code.
Rather than having a class file within the same project, one approach would be to have a separate project which compiles to a separate assembly. This would contain your entity framework goodies and a business layer to perform the CRUD.
The main website project would then reference this assembly. You could then deploy the project in a multi-tiered scenario.