I feel like exposing an edmx class as a parameter to a web service is not a good idea. I feel like it's wrong design. eg.
[WebMethod]
MyWebservice(int customerID, UserProfile profile){
}
now UserProfile is a class generated by Edmx framework. You might argue if the profile object is an input then it will not get a proper id (edmx id) because it will be created out of the context (since the web service can be called from any external consumer).
But i'm also looking for more explanation why exposing edmx class as a web service is not a good design. If you think it's ok, please tell me.
thanks
It's generally considered good design practice to keep the data contracts of a web service and the data model objects associated with a database separate, so that if required you could change the entity model used at the back of a web service, without having to change the interface that you expose to consumers of the service.
Related
I'm using Django Rest Framework and it's integrated with an external service. I'm using an endpoint to receive a callback from a webhook whenever a new task is created in the external service.
When the callback request comes in, my code needs to create at least one object. But it's possible that multiple objects will need to be created from multiple different models. For example, if a new task is created it's possible that it was created by a new user, in which I also need to create a new user object to reflect this.
In total, there could be up to 5 additional objects made as side effects. I'm aware of multiple different places that this logic could be added (e.g. service layers, serializers, models, managers, views). But there seem to be issues with all of these.
Has anyone dealt with this issue before? If so, how did you solve it?
First of all, it is important to understand the difference between an RPC-style API and a RESTful API. Simply put, you can imagine an RPC API to be "methods" that are "actions", while a RESTful API represents the state of your models.
For example, let's say we want to create an endpoint to handle user registration.
A RPC style endpoint might be /api/register. A register function that might do X number of things.
A REST style endpoint might be /api/users. Not an action, but simply just an endpoint that give us the state of the users that exist. A GET request would list the users and a POST request would create a new user.
With that said, it might be a bit more clear that in general, creating endpoints that do X number of actions might not be very "restful", and using a framework specifically named "Django REST Framework" might not be the right choice.
So in your particular case. I suggest that you avoid creating endpoints that work as methods, and instead treat them as the resources that they represent. This means that if you need to create a new user, you do a request to the user-endpoint, then if you need to create a new article with that user, you do a second request to the article-endpoint.
Using Signals for Side Effects
I think if you do want side effects, they should be managed using signals. For example, let's say that you want to send out emails using a contact form. Instead of having a /api/send_email endpoint, you instead do a /api/messages/ endpoint that represent a Message model, and then you use signals to send out emails whenever a new message is created.
By doing things this way, it still means that the API endpoint itself just represent the state of the model, while the side effect of modifying the state (sending a message on creation of a new message) is moved to the signal's responsibility.
Edit: Thank you for the answers. They are helpful. My last question is, is it possible to do this via REST?
To start, I realize these have already been somewhat answered in the following two links, so please do not close this as a duplicate. I am legitimately confused!
MVC vs. 3-tier architecture?
MVC Vs n-tier architecture
From what I understand, the MVC design is for the "presentation" tier in the 3-tier architecture to allow for GUI creation. I get that. However, where I am confused is how the data model in the GUI is supposed to interact with the "Tier 2" application logic. This is how I am envisioning it:
So from what I gather, whenever a user interacts with the GUI, and the Model is updated, is it the model's responsibility to then talk to the rest of the architecture via a web server API?
Your controller contains the lightweight application logic, which is needed to coordinate work between model and view. For example, your controller has the responsibility to get the data from a service/data source, and map the resulting model into a view model that is given to your view.
Views should also contain as little logic as possible. As the view model is created specifically for a view, the only responsibility of the view is to render itself using the view model's data.
The model you are referring to is indeed the result of what you get back from the back-end. It could be proxy entities returned by a WCF service, data entities returned by a web API or entity framework objects if you access the database directly (all depends on what architecture you want to use). This model is then used to construct a view model, which your view uses to render itself.
Depends on how you wanna structure your project.
For example: Sometimes we don't want to expose our model classes (entities). So, we create DTO classes to receive information from UI, that will be handle by controllers and pass them to business logic that translate them to entities. It's used a lot in SOA solutions, where we can expose ours services.
Example: UI request -> Controllers with DTO -> BLL (translate to real model classes) -> Repository/DAO -> DB.
Discussion of tiers is really orthogonal to discussion of MVC.
MVC doesn't really talk about how the model is supposed to talk to outside services/data layers. There are some good discussions here about it. There is debate as to whether data access/persistence should be in your model layer, or your controller layer. I much prefer it in my model layer.
I also prefer the Anemic Domain Model, so I tend to put the actual talking to the DAO layer in the service part of the model, not the domain objects. But putting it into the model objects works well too, you just want to separate your persistence layer from your business logic layer with the DAO pattern.
The point is though, both your tiers need their own Model, and their own DAO layers. The DAO layer of the Presentation Tier will talk to the Business Tier. The DAO layer of the Business Tier will talk to your Database/Storage Tiers.
This isolates each tier from changes in the other tiers.
I need an axample to use CodeIgniter restful because this class can't work:
class Books extends REST_Controller
{
.....
}
I need to create a single point of access to both the login and for the register so that the register in a system the user has access to all the others, then I will have only one database to store and query data from users. My question is: What is the best option when it comes to Webservice, SOAP or REST? I read that SOAP is heavier and slower, however also read that REST has fewer features. What do you suggest me? Login via Webservice safe?
While working on a new application I came across a new, for me, scenario. Our identity system is a stand alone application with it's own data store only accessible though REST APIs. This is the theme we're moving forward with, independent apps that talk to each other through APIs.
Some entities in my new app have natural associations with identity entities on the IDM app.I can store a reference to that entity's Id as reported to my app through its API. I'm thinking it would be better to store the full URL where I can GET the entity.
Does anyone have suggestions on which way to go?
MyEntity
- User: IDM issued ID
or
MyEntity
- User: https://idm-server.com/users/{id}
Thanks in advance
I have a two repositories Catalog and User, I have a situation where I need to call a method within the catalog repo from the user repo, is this good practice or is there a better way?
You shouldn't be handling those kind of authorization checks within your Repositories. A business rule like "This user requires X comments to post" isn't really a repository query, it's a property of your User.
Also, authorization calls are made very frequently in an application, and you really don't want to hit your database every time a check is required.
You should properly load these permissions into your User object which is then cached for the current request, and use your domain:
public class Service {
public void Save(Post post)
{
if(User.GetCurrentUser().HasEnoughCommentsToPost())
postRepository.Add(post);
}
}
I would reference the other Repository at the upper layer, such as a service layer
I think that in your case authorization is part of your domain logic. So I'd create an abstract class or interface called AuthorizationPolicy (maybe you can find a better name closer to your domain), in my domain layer. Before you call a method on the repository, the client should check if the have have permission based on the policy.
Another solution, because the interface of a repository is also part of the business logic, you can create a base class for your repository which check permissions of the user and delegate the rest to derived classes.
The implementation of the AuthorizationPolicy will talk to the Catalog class if you want. This way the two repositories are well decoupled.