I am using teams graph api, this api need to pay, and I also met the exception, which told me to pay for it, but I can't find how to pay it from the given link, the link is as below:
https://learn.microsoft.com/en-us/graph/teams-licenses
In additional, I also want to know if I continue to use the Evaluation Mode after paid, it seems there is no price for Evaluation Mode, so I have to use Model A or Model B?
Best Regards
Please follow this document for billing/payment: https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription
Evaluation model should only be used for testing the API. You cannot use evaluation mode once you reach the evaluation quota for that month. You will need to choose from either Model A or Model B. Model A is license based model and Model B is consumption based model. The requirements for the different models are specified in this document: https://learn.microsoft.com/en-us/graph/teams-licenses
Related
I am pretty new to using Google AutoML and I was wondering what the best practice was in the following scenario.
My goal is to update a Google AutoML Translate model without having to change the API call to get translations, and I am not sure if this is possible.
Currently the only way to update a AutoML Translate model is to create a new model, base it on the old one, and train it on the new examples (This is at least what seems to be the case). And when you make an API request to get a translation, you must specify which model you want to use by giving the identifier of that model. Because the old version of the model and the new version have different identifiers does this mean that every API call must be changed so that it uses the new model? Is there any way around changing the API call?
First of all, indeed the only way to update an AutoML Translate model is to create a new one, base it on the old one, and train it with the new examples. This is a clear security measure so you do not loose the old model in the process. Although on paper training with more sentences should help the model accuracy/performance, doing so might hinder the accuracy instead.
Second of all, the API call needs to be changed accordingly. You could code the API call in a way that uses the last model submitted so it does not need to be changed every time you update the model.
To do so, the first idea that comes to my mind is using a cloud function that gets triggered once a model is trained/created and stores the model-id in a bucket in GCS that the code performing the API calls recovers.
Nevertheless, the model performance should be assessed before assigning the translation calls from one model to the other, so I do not recommend simply changing it to the newest version without additional checks unless it is for testing purposes.
After reading https://softwareengineering.stackexchange.com/questions/165444/where-to-put-business-logic-in-mvc-design/165446#165446, I am still confused as to where I want to put my code for computing discounts. Computing a discounted price for a product or service I think is definitely part of business logic and is not part of application routing or database interaction. With that, I am struggling where to place my business logic.
Example
class Model
{
public function saveService($options)
{
$serviceId = $options['service_id'];
//Model reads "line Item" from database
$service = $this->entityManager->find('Entity\ServiceLineItem', $serviceId);
//uses the data to compute discount
//but wait.. shouldn't model do CRUD only?
//shouldn't this computation be in Controller?
$discount = ($service->getUnitPrice() * 0.25);
// Add the line item
$item = new SalesItem();
$item->setDiscount($discount);
}
}
class Controller
{
function save()
{
$this->model->saveService($options);
}
}
Question:
Above $discount computation, should it stay in Model, or does it go into Controller? If it goes into Controller, Controller has to call $service (via Model) first, then compute $discount inside Controller then send it the value back to the Model to be saved. Is that the way to do it?
Note
I may be confusing Model with "Storage". I probably need to have a Model where I do business logic and Database/Persistent Storage should be a separate layer.
Business logic belongs in a Service, so you would need to add a service layer.
Business logic tends to span multiple models, which infers that it does not belong in any single model. Therefore, it is unclear in which model you should put the logic.
Enter the service class.
I tend to make a service for each use-case the software is designed for.
In your case there could be a CheckOutService which would calculate your total sum, including discounts.
That way each service has a specific and intuitive purpose. Then, when a controller requires some business logic, it calls a service tailored for that very purpose.
A good description of what a service does in the MVC pattern can be found here:
MVCS - Model View Controller Service
I'll quote the most essential part:
The service layer would then be responsible for:
Retreiving and creating your 'Model' from various data sources (or data access objects).
Updating values across various repositories/resources.
Performing application specific logic and manipulations, etc.
edit: I just saw kayess answer. I'd say his answer is more precise than mine, but I don't know how relatable it is, given the degree of uncertainty in your question. So I hope mine can help some people in the earlier stages of their programming career.
Answering a question like this is usually opinionated or one could say it really depends on your business use case.
First off, i sense some mixup in your Model and service wording here.
A model should be your domain model, and service should either be a domain or an application service, in a different class or a different layer.
Architecturally thinking you could follow a rather simplified DDD-ish implementation.
Namely:
You implement all behavioural concepts in your domain model, which are related to the models current state
Use a factory that will query the line item from the repository
Use a domain service for mostly everything that's not related to your model, in your case calculating discount (if you need that logic reusable, for example in more models or services). You don't want to pollute your domain model with non related mechanisms and dependencies
For persistence you better use a different layer and by this you better separate most concerns you can, a reason for this is testability and another reason -amongst many others- for less code changes later
To achieve a cleaner architecture and less pain by maintaing your code in the longer run, don't forget to think about how design patterns and SOLID principles could help you implement your solution to the given business use case.
The question about how to separate business logic from data is not easily answered. However, Daniel Rocco has constructed a good discussion of the subject that you may find helpful, if not for this particular problem, then for structuring business applications in general.
I used a framework called "Yii Framework" using MVC, what it had was a function called beforeSave() in the controllers that was used to change the model values just before saving them.
Following this logic maybe the best practice would be to apply the discount to your price just before saving the model (in your Controller)
The Below Image shows how I think where your "Business" logic should go :)
The above image has the "Service" layer as the Server Side "Controller".
It is the middle man between the "Client" side Controller and the "Logic" layer.
All of your tasks that requires some type of "Logic" like
"Computing a discounted price for a product or service"
Would go into a ProductLogic Class where it takes inputs From the Service if needed and uses that information to help calculate the discounted price.
The ProductLogic Class will also query a "Data" source if needed to get the current price of an item.
The ProductLogic Class will piece together the information it collected from the Service and Repository to make the calculation and if it needs to be return to the user then the ProductLogic class will send it to the Service layer.
If it just needs to be saved in the Repository than the Logic will pass off the information to the Repository to handle.
Hope this helps :)
Have a great day!
I am involved in a research project where we try to find correlation between demographics and restaurant types. We want to have an interface where we can apply the demographic information over a map of the city as filters and check how the restaurant types and information changes.
I am lost on what sort of tools to use for this purpose.
Note: I am not sure whether this is the right place to post this question. If there is a specific SO site for this, I will move it there.
There isn't a specific SO site for openstreetmap, but even better there is a https://help.openstreetmap.org/ site which would be an even better place to ask.
Example 1:
A Model class "News" stores its text in two different languages (fields: en_text, jp_text). Usually it has text in only one language. Should I translate the text in callback before_save using the Google Translate API, or should I place this code in the Controller?
Example 2
A Model class "Payment". When the payment is going to be settled, the system must notify an external service about the successful settling of the payment. Where should this code be placed, Model or Controller?
The model is usually used to "get" or "set" data, so technically speaking, if your external service provides a service to "get" or "set" data, then yes.
Your Models should be literally the whole business logic of your application. Requirements for your Application mean that you should translate your text or notify some service on payment, don't they? That means that you should write it in your Model.
Controller is an entity that processes request parameters to some business logic actions. Controller should not contain such parts.
As I know, you are using Rails for now, so look at following links (this patterns are also helpful for non-Ruby programmers):
http://api.rubyonrails.org/classes/ActiveResource/Base.html
http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model - classics :)
How do you apply validation in an MVP/domain environment ?
Let me clearify with an example:
Domain entity:
class Customer
{
string Name;
etc.
}
MVP-model
class CustomerModel
{
string Name;
etc.
}
I want to apply validation on my domain entities but the MVP model has it's own model/class
apart from the domain entity, does that mean I have to copy the validation code
to also work on the MVP-model?
One solution I came up with is to drop the MVP-model and use the domain entity as MVP-Model,
but I don't want to set data to the entities that isn't validated yet.
And second problem that rises is that if the entity has notify-events,
other parts of the application will be affected with faulty data.
A third thing with that approach is if the user edits some data and then cancels the edit, how do I revert to the old values ? (The entity might not come from a DB so reloading the entity is't possible in all cases).
Another solution is to make some sort of copy/clone of the entity in question and use the copy as MVP-model, but then it might get troublesome if the entity has a large object graph.
Anyone has some tips about these problems?
Constraining something like the name of a person probably does not rightfully belong in the domain model, unless in the client's company there is actually a rule that they don't do business with customers whose names exceed 96 characters.
String length and the like are not concerns of the domain -- two different applications employing the same model could have different requirements, depending on the UI, persistence constraints, and use cases.
On the one hand, you want to be sure that your model of a person is complete and accurate, but consider the "real world" person you are modeling. There are no rules about length and no logical corollary to "oops, there was a problem trying to give this person a name." A person just has a name, so I'd argue that it is the responsibility of the presenter to validate what the user enters before populating the domain model, because the format of the data is a concern of the application moreso than the domain.
Furthermore, as Udi Dahan explains in his article, Employing the Domain Model Pattern, we use the domain model pattern to encapsulate rules that are subject to change. That a person should not a have a null name is not a requirement that is likely ever to change.
I might consider using Debug.Assert() in the domain entity just for an added layer of protection through integration and/or manual testing, if I was really concerned about a null name sneaking in, but something like length, again, doesn't belong there.
Don't use your domain entities directly -- keep that presentation layer; you're going to need it. You laid out three very real problems with using entities directly (I think Udi Dahan's article touches on this as well).
Your domain model should not acquiesce to the needs of the application, and soon enough your UI is going to need an event or collection filter that you're just going to have to stick into that entity. Let the presentation layer serve as the adapter instead and each layer will be able to maintain its integrity.
Let me be clear that the domain model does not have to be devoid of validation, but the validation that it contains should be domain-specific. For example, when attempting to give someone a pay raise, there may be a requirement that no raise can be awarded within 6 months of the last one so you'd need to validate the effective date of the raise. This is a business rule, is subject to change, and absolutely belongs in the domain model.