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 )
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 3 years ago.
Improve this question
I have a WCF Service which maps EF Entities to DTOs to send the data to a WPF Client application, when the WPF Client updates the service reference it generates all of the DTOs (as partial classes) defined at the Service.
My question is: on the WPFClient side should I directly take these DTOs as Models and extend them using partial classes to add extra fields, methods to fetch the data, etc. Or should I create a new class and map again from the generated DTOs to the new class?
I would consider creating new objects, treat your DTOs simply as "transport" objects. You don't want to risk ending up with functionality, if any, business logic in your DTOs.
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
We have to microservices.
How can we use an entity model from one microservice to another microservice without needing to maintain codes on both end?
The goal is to take the jsonData from a microservice and map it to entity model that exist in another microservice.
What is the best practice here?
You will need the assembly that contains the types you want to serialize/deserialize jsons. I think it is ok because when you have one service, you expect it to run autonomously, so, if you provide additional fields it should work (because it will not be affected by the deserialization). Now missing fields, the service will thrown exceptions and it is expected as part of the business.
One option, but not recommended (in my opinion), is to deserialize your json into dynamic and you will be able to navigate on the result as you want. I am not sure about the performance of this.
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
I work on school enterprise project and I need create data layer with design patterns. Can you give me some hint where to start and how patters could I use ? Thanks
Edit:
I have not use frameworks for ORM.
You could try the repository pattern and unit of work pattern
One of the common pattern for the data layer is the Data Access Objects. Anyway you can also use ready-to-use libraries such as the Microsoft Solution Entity Framework or NHibernate.
Also you can read this link with a lot of suggestions
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.
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 9 years ago.
Improve this question
Recently I'm reading an article about http://ardalis.com/n-tier-design-lessons-learned-part-1 which introduce the evolution of n-tier application but one thing was not explained is the WorkFlow layer can anyone one explain what's the workflow layer and give us a real world application example with c#.
From here:
By creating a workflow tier a company has essentially avoided
hardcoding workflows into one of the other tiers. By creating a
workflow layer, we will gain the added flexibility easily
customizability that a tier provides. We will gain improve
manageability of the workflow tier by extracting the layer. For
example, when the end user requests changes to the workflow, by
creating a specific workflow tier and thus isolating the
responsibility of workflow the resulting code changes will be
minimized to just the workflow tier. The impact on other tiers will be
minimized.
Also check To Workflow or Not to Workflow?