It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am using simple 3 tier architecture.
In this I am using DTO classes to communicate between UI,BL and DL.
So there is any better way for communication between layers? or this is the right way?
DTO, Data transfer Object, is the concept for distribution layer, you use when transferring data between your consumers and your service. So, if you don't publish any service, get off DTO.
To answer your question, it also depends on how complex your application is. If it's simple, just use CRUD operation, or you can even use DataTable, DataSet for communication.
Otherwise, Domain Entity from DDD is the core object for communication between layers: Data Access Layer, Business Logic Layer and Presentation Layer.
Basically, there are some different type of objects in application:
DTO, use when you public services, main object to communicate between consumer and your service.
View Model, object in presentation layer to support UI.
Domain Entity is from Business logic layer to contain business logic.
Be careful with the term:
Tier: it means physical, like database server, web server.
Layer: it means logical layer: Persentation Layer, Business Logic Layer, Data Access Layer.
Read this tutorial it is very informative. It will help you to decide is DTO right for your scenario.
In addition to #Talha's answer, I'd recommend this article. It is EF-oriented, but concepts, described there, are common ones.
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
I have been working with asp.net core web api for the past few days, I am familiar with MVC and SOC etc but I got confused a bit with the core mvc tutorials.
So in all the tutorials (to keep them simple) they put the business logic inside the Controller, but this is ofcourse not compliant to MVC.
In general I have created:
Model (to create the DB structure through EF)
Controller (to serve the endpoints and act)
Repositories (to provide the query logic to the DB)
Now I am bit confused with Services and also where am I supposed to put the business logic? I mean the Model is one place, but I dont want my controller to access the model directly but more like a Facade/Factory.
How do we achieve this in aspnet?
You can find my working repo at https://github.com/drakoumel/DatacircleAPI
I hope that after I can get a good explanation of this, to write it in the documentation of stackoverflow to help others.
There are so many approaches to this and there is not a single correct answer to your question.
Basically, the models you use in your views should not be the ones, that you persist in your database. Therefore, what you can do for example, is create a 'service' layer, so controllers operate on services, and services operate on repositories. This way you achieve a clear separation of concerns between each 'layer'.
First of all, keep persistance models and business logic out of controller. The only logic that belongs to a controller is application logic.
Secondly, introduce business logic layer (AKA. services layer), in which your business logic belongs. You can also create separate models in that layer, so your controllers do not operate on the models that represent your database entities, and you just apply mappings between models that services expose to your controllers and models that they pass to the repositories. Take those services as dependencies to your controllers. Your services will also take your repositories as their dependencies.
This way your controller has no idea what your business logic is - it only knows that it has to call some service which takes care of everything. Your service has no idea about where it's being used, he knows nothing of controllers, views or the way your data is presisted in the database - it just executes your business logic. And your repositories just persist your entity in storage of your choice, they only know their entity model and how to persist it. They haven no knowledge that there are services, controllers or views. The benefit which you get from is that when you decide to change your code, whether it's the business-validation logic of minimum allowed customer age or the mechanism or saving your entity, you are likely to do it in just one place in your code, place that is responsible for that specific thing.
Keep in mind that is the minimal separation of concerns between those components that you can do. Be aware that everything depends on your case and creating simple layers between presentatio, business logic and data persistance layers is not always the right or trivial thing to do, as it might sometimes be tricky not to leak your business logic into layers other than where they actually belong.
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
I have earlier developed an application that exposes a set of RESTful services. I have designed business logic implementation classes and corresponding repository classes completely stateless and they get instantiated every time there is client request. Now I am developing another application with few RESTful services. In this case, one of the services gets data from some other external service and needs to cache that data for some amount of time. I am thinking to cache that data in my application DB and provide it for each request by creating a new business class object. But here I have a doubt - is this correct design? Should I make the business logic class singleton and maintain state (i.e., cache data in memory)?
Please share your thoughts.
Thanks
I would use web server level caching instead. In asp.net you can use the Cache object, either backed by memory or an external cache provider of your choice.
After some literature study, I conclude that there is nothing wrong in having singleton classes. RESTful services are just resource interfaces for external world but how they will be managed is completely internal. Also I realized there is no need to have end-to-end mappings from data transfer objects (that take requests and send responses) to database columns. My DTOs, in many cases, map to model objects which map to DB tables but I have also designed those three items differently.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Interface should be used when none of the implementation details are available to the current scope of the code.
Abstracts should be used when some of the implementation details are available to you.
Query - Why still these terms are required? Why can't Business objects directly communicate with DataAccess.SqlServer Layer?
Interface should be used when none of the implementation details are
available to the current scope of the code.
Not really. What you're referring to is encapsulation. There is the concept of "information expert." Only the class that knows how to do something should be the one doing it. Interfaces are used for polymorphism and decoupling. When consuming code wants to treat certain types of objects the same way, that code can use all of those objects the same way by treating them as the interface type.
Abstracts should be used when some of the implementation details are
available to you
I'm not sure what you mean here. I think you're confused because this doesn't sound right. Abstract classes are used the same way interfaces are, except that they're allowed to have implementation in them.
Query - Why still these terms are required? Why can't Business objects
directly communicate with DataAccess.SqlServer Layer?
They can, but at the cost of maintainability, flexibility, and testability. If you want to replace your data layer with another, you can't because the consuming code has a direct dependency on the current data layer. If you want to unit test your logic, you can't without hitting the DB. If you put your database classes behind an interface, you could mock the data layer in unit testing and test your logic classes without hitting the database.
Very Short Example
public Foo FooLogic
{
IFooData fooData = DataAccessFactory.GetDataClass<IFooData>();
return fooData.GetFoo();
}
Now your logic class isn't tied to a particular data class. The factory can return a real FooData implementation, or it can return a mock data object, or a new data access layer can be put in place without affecting the code in the logic class.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Can someone please explain which part of the provider model best represents the business layer?
Where should the business rules and business logic live?
If you mean something like the Membership Provider in .net, I would say the Business Layer uses the providers as a service (like John states). Though the line is a little gray if you are implementing providers yourself (like is a user a business object? if so what about the rules in the provider logic?).
Typically providers are developed separately from business applications because they are more infrastructure type code.
However, if you are just interested in the provider portion then, you typically have the following parts in a provider:
1. infrastructure stuff (config reading/database communication/etc)
2. provider interface (provides the service to consuming code)
3. 'business' objects and rules
I guess the business layer would be the implementation of the specific provider (there is usually a base class that implements the infrastructure stuff). For instance the membership provider deals with user and membership objects and has a few rules on how to do what it does as a provider.
Unless you're talking about a different "provider model" than I am, there is no relationship to a business layer.
A provider model is simply an architecture where one or more components provides a set of services. For instance, in LINQ, a LINQ Provider provides the mapping to a data store or other source of data, while the .NET Framework classes provide the rest.
What are the possible data access layer design-patterns for c# applications ?
Any advice will be useful.
Thanks.
Despite the question being somewhat broad, you might find Spring.NET's DAO support helpful (particularly the ADO chapter).
A lot of data access layer design-patterns are described here. 3 tier architecture with data mapping is widely spread