Develop Reference

Owned Entity with Polymorphism EF core 6

Bonjour
I need some help to understand how we map OwnedEntity when they are polymorph.
I have this inventory hierarchy of records that are linked to a product class .
public abstract record Inventory
{
protected Inventory() { }
}
public record NoProductInventory : Inventory
{
public NoProductInventory()
{
}
}
public sealed record ProductLevelInventory : Inventory
{
public int Stock { get; private set; } = default!;
public int LowStock { get; private set; } = default!;
protected ProductLevelInventory() {}
public ProductLevelInventory(int stock, int lowStock) : base()
{
Stock = stock;
LowStock = lowStock;
}
}
public sealed record VariantLevelInventory : Inventory
{
public int Stock { get; private set; } = default!;
public int LowStock { get; private set; } = default!;
public int SomeOption { get; private set; }
protected VariantLevelInventory() {}
public VariantLevelInventory(int stock, int lowStock) : base()
{
Stock = stock;
LowStock = lowStock;
}
}
The Product class Definition
public class Product
{
....
public Inventory Inventory { get; private set; } = default!;
....
}
I am using fluent API in order to mapped those entities
public class ProductEntityTypeBuilder : IEntityTypeConfiguration<Product>
{
public void Configure(EntityTypeBuilder<Product> builder)
{
builder.OwnsOne(x => x.Inventory, bld =>
{
bld.ToTable("Inventories");
// bld.Property(x => x.TrackInventory).IsRequired();
bld.Property(x => x.Stock).IsRequired(false);
bld.Property(x => x.LowStock).IsRequired(false);
// bld.Property(x => x.InventoryTrackType).IsRequired(false);
});
}
}
My question is: how can I tell EF which Inventory record to use? I don't want to use casting to figure out what kind of inventory a product has.
Good Day !

Owned entities are meant to be used as value types, containing and encapsulate multiple values which belong together and don't have a meaning on their own, i.e. MonetaryAmount which consists of a Amount and a Currency property.
You can't do this right now. If you need hierarchies, you have to convert your owned types into entities and use it as regular navigation properties on the base type which are distinguished via a discriminator.
Owned types do not support inheritance Owned Types: Shortcommings
Current shortcomings
Owned entity types cannot have inheritance hierarchies

How to make authorization to specific field in specific object in ASP.Net Core?

I need to check privileges to specific field in specific object in database.
Let's make and example. I have Model called Employee
public class Employee {
[Key]
public int EmployeeID { get; set; }
public string JobTitle { get; set; }
public string Description { get; set; }
public int Salary { get; set; } // <---- Restricted
public int BossID { get; set; }
}
And I have a few cases:
I need to restrict access to specific field Salary because I don't want anyone to see each other salary. But HR can see anyone Salary and edit it. If I'm this employee I can see my own Salary, but cannot edit it.
Everyone can see each other job titles, but only HR can edit it. And also boss of that employee, can edit, by employee himself cannot.
Use case:
I'm manager with RoleID 4. I want to see Salary of my Employee named John Smith with EmployeeID 5. I can do that.
I'm manager with RoleID 4. I want to see Salary of 'Employeenamed Mark Twain withEmployeeID` 8. Mark is not but my directly subordinate. He is from different branch. I cannot do that.
I'm employee with EmployeeID 5 and I want to see my Salary. That's allowed.
I'm employee with EmployeeID 5 and I want to edit my own Salary. It's forbidden. I get HTTP Error 401.
I'm from HR. I can see and edit Salary of all Employees in company.
I though of something like this:
public class Access {
[Required]
public int RoleID { get; set; }
[Required]
public string TableName { get; set; }
[Required]
public string ColumnName { get; set; }
[Required]
public int RowID { get; set; }
}
And then check (by Authorize attribute) if specific role (boss, HR or something) has access to specific field (for example Salary) for specific data (for example Employee with id 22). That's a lot of "specific"by the way.
How should I do it? Is my idea 'OK'?

In case when logic is less complicated or more generic, it's possible to set custom output formatter to prevent some fields to be written into the respose.
The approach has next problems:
Shouldn't handle complicated logic. As it causes business logic spread to the multiple places
Replaces default serialization. So if there are specific serialization settings are set in Startup, then it should be transfered
Let's see an example.
There could be a custom attrbute like
public class AuthorizePropertyAttribute : Attribute
{
public AuthorizePropertyAttribute(string role) => Role = role;
public string Role { get; set; }
}
Then output formatter could be like:
public class AuthFormatter : TextOutputFormatter
{
public AuthFormatter()
{
SupportedMediaTypes.Add(MediaTypeHeaderValue.Parse("application/json"));
SupportedEncodings.Add(Encoding.UTF8);
}
public override async Task WriteResponseBodyAsync(OutputFormatterWriteContext context,
Encoding selectedEncoding)
{
var settings = new JsonSerializerSettings
{
ContractResolver = new AuthorizedPropertyContractResolver(context.HttpContext.User)
};
await context.HttpContext.Response.WriteAsync(
JsonConvert.SerializeObject(context.Object, settings));
}
}
That would require
public class AuthorizedPropertyContractResolver : DefaultContractResolver
{
public AuthorizedPropertyContractResolver(ClaimsPrincipal user)
{
User = user;
}
public ClaimsPrincipal User { get; }
protected override JsonProperty CreateProperty(MemberInfo member,
MemberSerialization memberSerialization)
{
var result = base.CreateProperty(member, memberSerialization);
result.ShouldSerialize = e =>
{
var role = member.GetCustomAttribute<AuthorizePropertyAttribute>()?.Role;
return string.IsNullOrWhiteSpace(role) ? true : User.IsInRole(role);
};
return result;
}
}
Registration:
services.AddMvc(options =>
{
options.OutputFormatters.Insert(0, new AuthFormatter());
});
In that case Response for simple user will lack of the Salary field {"Id":1,"Name":"John"} at the same time manager will see the full response
{"Id":1,"Name":"John","Salary":100000}, ofcourse the property "Salary" should have attribute set
[AuthorizeProperty("Boss")]
public double Salary { get; set; }

You should implement 2 different methods. One is for the HR when requesting the data, and the other is for the simple user. Then you never should return the whole object (json), instead, create some DTOs (Data Transfer Object) that holds the desired data. So lets make an example:
public class DTOGetEmployeeByEmployee {
public int EmployeeID { get; set; }
public string JobTitle { get; set; }
public string Description { get; set; }
public int BossID { get; set; }
}
public class DTOGetEmployeeByHR {
public int EmployeeID { get; set; }
public string JobTitle { get; set; }
public string Description { get; set; }
public int Salary { get; set; }
public int BossID { get; set; }
}
Once a user requests that employee, get it from the Database, and then convert it into the desired DTO. Best way I saw so far is using AutoMapper to do so:
Mapper.Map<DTOxxxx>(yourObject);
You can also use the [Authorize] Attribute to check if the User is HR or an Employee. I did this multiple times combined with JWT-Token.
public class EmployeeController
{
[Authorize("HR")]
[HttpGet, Route("GetForHR")]
public IActionResult Get(int employeeID)
{
// Note: this is just a sample out of my head, so there will be adjustments needed in order to run that
// Check if the HR is allowed to access the Employees data
// Get the Employee by its ID
var emp = ...;
// Convert it to the DTO
var dto = Mapper.Map<DTOGetEmployee>(emp);
// return the dto
return Ok(dto);
}
}
I bet there are plenty of better solutions out there, but for me, this is super simple, wasy to reimplement in other applications and there is no palpable performance loss

C# "Rename" Property in Derived Class

When you read this you'll be awfully tempted to give advice like "this is a bad idea for the following reason..."
Bear with me. I know there are other ways to approach this. This question should be considered trivia.
Lets say you have a class "Transaction" that has properties common to all transactions such as Invoice, Purchase Order, and Sales Receipt.
Let's take the simple example of Transaction "Amount", which is the most important monetary amount for a given transaction.
public class Transaction
{
public double Amount { get; set; }
public TxnTypeEnum TransactionType { get; set; }
}
This Amount may have a more specific name in a derived type... at least in the real world. For example, the following values are all actually the same thing:
Transaction - Amount
Invoice - Subtotal
PurchaseOrder - Total
Sales Receipt - Amount
So now I want a derived class "Invoice" that has a Subtotal rather than the generically-named Amount. Ideally both of the following would be true:
In an instance of Transaction, the Amount property would be visible.
In an instance of Invoice, the Amount property would be hidden, but the Subtotal property would refer to it internally.
Invoice looks like this:
public class Invoice : Transaction
{
new private double? Amount
{
get
{
return base.Amount;
}
set
{
base.Amount = value;
}
}
// This property should hide the generic property "Amount" on Transaction
public double? SubTotal
{
get
{
return Amount;
}
set
{
Amount = value;
}
}
public double RemainingBalance { get; set; }
}
But of course Transaction.Amount is still visible on any instance of Invoice.
Thanks for taking a look!

Thanks for all the help.
OK, of course you cannot "hide" public properties on the base class when the derived class IS a base instance. Somewhere deep in my brain I already knew that. Doh!
I wound up getting the syntactic sugar to behave the way I wanted for the consumer by using a third class called TransactionBase. This class is abstract and contains the shared, non-aliased stuff that exists for all transactions like currency, exchange rate, created/modified date and time, transaction date, etc... in addition to aliased stuff like Amount.
Here, I just show the Amount property in question:
public abstract class TransactionBase
{
protected virtual double Amount { get; set; }
}
Then Transaction looks like this:
public class Transaction : TransactionBase
{
public new double Amount
{
get
{
return base.Amount;
}
set
{
base.Amount = value;
}
}
}
And Invoice:
public class Invoice : TransactionBase
{
public double SubTotal
{
get
{
return Amount;
}
set
{
Amount = value;
}
}
}
And access works the way I wanted:
var transaction = new Transaction();
// This line works fine:
var transactionAmount = transaction.Amount;
var invoice = new Invoice();
// This line works fine:
var invoiceSubtotal = invoice.SubTotal;
// This line won't compile.
// Error: TransactionBase.Amount is inaccessible due to its protection level.
var invoiceAmount = invoice.Amount;
So the answer to my original question was, "no" you cannot hide public inherited members. The above solution fakes it with accessing the protected member directly in the derived types, but it still sort of sucks. Too much typing.
Of course, now that I fiddled and piddled with all that, I'm seeing that a better solution throws out the protected members altogether and saves me some typing. By the way, YES I am embarrassed that I didn't jump immediately to this solution.
EDIT: Actually, the first appraoch in my answer might be better. With the 2nd one, I'd lose the "Amount" or "Subtotal" when casting from a Transaction to an Invoice.
public abstract class TransactionBase
{
// There are some shared properties here.
}
public class Transaction : TransactionBase
{
public double Amount { get; set; }
}
public class Invoice : TransactionBase
{
public double SubTotal { get; set; }
}

In short, you can't do this.
In long, you can emulate this by coding to interfaces!
public class Transaction
{
public double Amount { get; set; }
}
public interface IInvoice
{
public double? SubTotal { get; set; }
}
public class Invoice : Transaction, IInvoice
{
public double? SubTotal
{
get
{
return Amount;
}
set
{
Amount = value ?? 0.0f;
}
}
}

I would recommend using composition over inheritance in this instance. The main reason is that the base implementation of Transaction seems to possibly never be used in the way intended through inheritance. You can hide the transaction as a protected or private member of the Invoice and expose / manipulate it using the public properties of Invoice.
One such example could look like:
public class Invoice
{
private readonly Transaction _transaction;
public Invoice():this(new Transaction())
{
}
public Invoice(Transaction transaction)
{
_transaction = transaction;
}
// This property should hide the generic property "Amount" on Transaction
public double? SubTotal
{
get
{
return _transaction.Amount;
}
set
{
_transaction.Amount = value ?? 0.0f;
}
}
public double RemainingBalance { get; set; }
}

The exact behavior you're looking for doesn't make sense syntactically. If Invoice inherits Transaction, then it is a kind of transaction, and the compiler requires it to inherit all of its properties.
The general behavior you're looking for is, I think, encapsulation, which can be accomplished with interfaces.
public interface IInvoice
{
double? Amount { get; set; }
}
public interface ITransaction
{
double? SubTotal { get; set; }
}
Require the consumers of your code to use these interfaces, and then the implementation details are hidden to them.
So now, the classes can behave the way you want. SubTotal will still be visible to the class (Invoice), but will be hidden to the interface (IInvoice).
public class Transaction : ITransaction
{
public double? SubTotal { get; set; }
}
public class Invoice : IInvoice
{
public double? Amount
{
get { return base.SubTotal; }
set { base.SubTotal = value; }
}
}

How about using an implicit conversion operator?
class Program
{
static void Main(string[] args)
{
var transaction = new Transaction();
var transactionAmount = transaction.Amount;
var invoice = new Invoice();
var invoiceSubTotal = invoice.SubTotal;
Transaction fromInvoiceToTrans = invoice;
var fromInvoiceToTransAmount = fromInvoiceToTrans.Amount;
}
}
public class Transaction
{
public decimal Amount {get; set;}
}
public class Invoice
{
public decimal SubTotal
{
get;
set;
}
public static implicit operator Transaction(Invoice invoice)
{
return new Transaction
{
Amount = invoice.SubTotal
};
}
}

Specific entity objects for Add and Update methods in a repository

I'm trying to come up with a way to design a repository where adding and updating only accepts the exact amount of data/properties it can add/update.
I have the following design:
public interface IProduct
{
int Id { get; set; }
string Name { get; set; }
decimal Price { get; set; }
DateTime Created { get; set; }
DateTime Updated { get; set; }
}
public interface IProductRepository
{
void Add(IProduct product);
void Update(IProduct product);
IProduct Get(int id);
IEnumerable<IProduct> GetAll();
}
However, the Created and Updated properties are not really something I want to be modified outside of the database. The Id is not relevant when adding either, so I tried the following:
public interface IProductAdd
{
string Name { get; set; }
decimal Price { get; set; }
}
public interface IProductUpdate
{
int Id { get; set; }
string Name { get; set; }
decimal Price { get; set; }
}
And updated the repository accordingly:
public interface IProductRepository
{
void Add(IProductAdd product);
void Update(IProductUpdate product);
IProduct Get(int id);
IEnumerable<IProduct> GetAll();
}
Now only the relevant properties are present in each individual method.
I could then create a class that implements all product interfaces:
public class Product : IProduct, IProductAdd, IProductUpdate
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
public DateTime Created { get; set; }
public DateTime Updated { get; set; }
}
So my question is: Is this the right way to do this?
My thoughts:
I could have opted to change the Add and Update methods on the Repository to accept every bit of product data as parameters, such as Update(int id, string name, decimal price), but it will get out of hand quickly when the amount of information a product holds increases.
My current solution involves repetition. If a product should hold a Description property, I would have to specify it in different 3 interfaces. I could let the interfaces implement each other to solve this...
public interface IProductAdd
{
string Name { get; set; }
decimal Price { get; set; }
string Description { get; set; }
}
public interface IProductUpdate : IProductAdd
{
int Id { get; set; }
}
public interface IProduct : IProductUpdate
{
DateTime Created { get; set; }
DateTime Updated { get; set; }
}
...but then I would get in trouble if IProductAdd were to have something that IProductUpdate shouldn't have.
Related problem: Let's say I want put products in categories, and have access to the category directly on each product.
public interface ICategory
{
int Id { get; set; }
string Name { get; set; }
string Description { get; set; }
}
public interface IProduct
{
int Id { get; set; }
string Name { get; set; }
decimal Price { get; set; }
DateTime Created { get; set; }
DateTime Updated { get; set; }
ICategory Category { get; set; }
}
When I change a product, I want to specify the id of the category (since I'm adding/updating the relationship, not the category itself):
public interface IProductAdd
{
string Name { get; set; }
decimal Price { get; set; }
int CategoryId { get; set; }
}
public interface IProductUpdate
{
int Id { get; set; }
string Name { get; set; }
decimal Price { get; set; }
int CategoryId { get; set; }
}
This results in the following implementation:
public class Product : IProduct, IProductAdd, IProductUpdate
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
public DateTime Created { get; set; }
public DateTime Updated { get; set; }
public ICategory Category { get; set; }
public int CategoryId { get; set; }
}
Looking at that, do I use Category.Id or CategoryId? Not ideal, IMO.
So I guess I see problems no matter how I do this. Am I too picky?
Am I looking at this wrong?
Should I just separate things completely because they ARE different things (eg. [the entity] / [add entity parameters] / [update entity parameters])?

I think you are over-complicating things while not separating your layers properly. In my opinion, the first two classes are how it should be done.
From what I understand, your whole issue is that you do not want the Created and Updated properties to be modified incorrectly. However, you are mixing up data and business concerns. Saying that a product's created date should be set upon the product being created is part of the business logic of creating a new product, and saying that a product's updateddate should be updated when x and y occur is also part of the logical process of updating a product's data. This is the same type of process as validating that the properties of the product are valid, the user is authorized, etc.., all of which are business process concerns, not data storage concerns.
Your repository should be solely part of the data layer, where it's only concern is how it retrieves the requested product from the database, how it updates a product in the database, or creates a product in the database. That's it.
You need a dedicated business layer that handles all the business logic for adding or updating a product's information. You will then call a method in this layer with the name and price of for the product you want to add, and in this method you will perform any validations you want to perform, determine if the user is authorized to be making these edits, and setting the CreatedDate or UpdatedDate if it's warranted. This method will then pass the Product entity to your repository to save it in the database.
Separating out the logic in this manner will make it MUCH easier when you want to change the logic on how things such as UpdatedDate is managed (maybe you want certain actions to change that date but not all actions). If you try and handle all of this in your repository/data layer, it will quickly become overwhelming and confusing when you get away from trivial use cases.
One other point. IProduct is a business entity, which means that you don't have to expose it to your presentation layer at all. Therefore, if you do not want to risk a developer touching certain properties, you can use what the MVC architecture usually calls ViewModels. Essentially, these are data structures that are used on the presentation layer, and the business layer can then translate these ViewModels into actual business entities.
So for example, you could have:
public class ProductViewModel
{
int Id { get; set; }
string Name { get; set; }
decimal Price { get; set; }
int CategoryId { get; set; }
}
Your presentation layer will pass a filled out ProductViewModel into your business layer's AddProduct() or UpdateProduct() methods, will then retrieve the database's IProduct entity for the one specified and use the ProductViewModel to determine how to update (or create a new) the database entity. This way, you never expose the two DateTime properties but still have full control over how and when they are set.

Forgive me if I've misunderstood you here but to me it appears that your design logic is incorrect. In essence your base entity is Product which has a number of actions Add, Update etc.
So why don't you declare base base IProduct interface which only has the minimum amount of properties required for all actions, e.g. description, category etc.
Then just get each of the actions e.g. IProductAdd inherit from this base interface. The product class itself should only inherit from the IProduct interface.
Then create new classes for each of the actions e.g. add which inherits from IProduct add & just add some methods in the product class which accept parameters of type IProductAdd etc. but which use instances of the action classes to perform work

This is how I'd go about it....I'd use reflection and attribute(s):
namespace StackOverFlowSpike.Attributes
{
[AttributeUsage(AttributeTargets.Property)]
public class ReadOnlyAttribute : Attribute
{
public ReadOnlyAttribute() { }
}
}
using StackOverFlowSpike.Attributes;
namespace StackOverFlowSpike.Entities
{
public interface IEntity
{
[ReadOnly]
public int Id { get; set; }
}
}
using System;
using StackOverFlowSpike.Attributes;
namespace StackOverFlowSpike.Entities
{
public class Product : IEntity
{
[ReadOnly]
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
[ReadOnly]
public DateTime Created { get; set; }
[ReadOnly]
public DateTime Updated { get; set; }
}
}
using StackOverFlowSpike.Entities;
using System.Collections.Generic;
namespace StackOverFlowSpike.Repositories
{
public interface IRepository<T> where T : IEntity
{
void Add(T item);
void Update(T item);
T Get(int id);
IEnumerable<T> GetAll();
}
}
using System;
using System.Linq;
using System.Threading;
using System.Reflection;
using System.Collections.Generic;
using StackOverFlowSpike.Entities;
using StackOverFlowSpike.Attributes;
namespace StackOverFlowSpike.Repositories
{
public class ProductRepositoryMock : IRepository<Product>
{
#region Fields and constructor
private IList<Product> _productsStore;
public ProductRepositoryMock()
{
_productsStore = new List<Product>();
}
#endregion
#region private methods
private int GetNewId()
{
return _productsStore
.OrderByDescending(p => p.Id)
.Select(p => p.Id).FirstOrDefault() + 1;
}
private void PopulateProduct(Product storedProduct, Product incomingProduct)
{
foreach (var p in storedProduct.GetType().GetProperties())
{
// check if it is NOT decorated with ReadOnly attribute
if (!(p.GetCustomAttributes(typeof(ReadOnlyAttribute), false).Length > 0))
{
// i will use reflection to set the value
p.SetValue(storedProduct, p.GetValue(incomingProduct, null), null);
}
}
}
private void Synchronise(Product storedProduct, Product incomingProduct)
{
foreach (var p in storedProduct.GetType().GetProperties())
p.SetValue(incomingProduct, p.GetValue(storedProduct, null), null);
}
#endregion
public void Add(Product product)
{
Product newProduct = new Product();
newProduct.Id = GetNewId();
newProduct.Created = DateTime.Now;
newProduct.Updated = DateTime.Now;
PopulateProduct(newProduct, product);
_productsStore.Add(newProduct);
Synchronise(newProduct, product);
// system takes a quick nap so we can it really is updating created and updated date/times
Thread.Sleep(1000);
}
public void Update(Product product)
{
var storedProduct = _productsStore.Where(p => p.Id == product.Id).FirstOrDefault();
if (storedProduct != null)
{
PopulateProduct(storedProduct, product);
storedProduct.Updated = DateTime.Now;
// system takes a quick nap so we can it really is updating created and updated date/times
Synchronise(storedProduct, product);
Thread.Sleep(1000);
}
}
public Product Get(int id)
{
Product storedProduct = _productsStore.Where(p => p.Id == id).FirstOrDefault();
Product resultProduct = new Product()
{
Id = storedProduct.Id,
Name = storedProduct.Name,
Price = storedProduct.Price,
Created = storedProduct.Created,
Updated = storedProduct.Updated
};
return resultProduct;
}
public IEnumerable<Product> GetAll()
{
return _productsStore;
}
}
}
Here is a small console program to test
using System;
using System.Text;
using System.Collections.Generic;
using StackOverFlowSpike.Entities;
using StackOverFlowSpike.Repositories;
namespace StackOverFlowSpike
{
class Program
{
static void Main(string[] args)
{
Product p1 = new Product()
{
Created = Convert.ToDateTime("01/01/2012"), // ReadOnly - so should not be updated with this value
Updated = Convert.ToDateTime("01/02/2012"), // ReadOnly - so should not be updated with this value
Id = 99, // ReadOnly - should not be udpated with this value
Name = "Product 1",
Price = 12.30m
};
Product p2 = new Product()
{
Name = "Product 2",
Price = 18.50m,
};
IRepository<Product> repo = new ProductRepositoryMock();
// test the add
repo.Add(p1);
repo.Add(p2);
PrintProducts(repo.GetAll());
// p1 should not change because of change in Id
p1.Id = 5; // no update should happen
p1.Name = "Product 1 updated";
p1.Price = 10.50m;
// p2 should update name and price but not date created
p2.Name = "Product 2 updated";
p2.Price = 17m;
p2.Created = DateTime.Now;
repo.Update(p1);
repo.Update(p2);
PrintProducts(repo.GetAll());
Console.ReadKey();
}
private static void PrintProducts(IEnumerable<Product> products)
{
foreach (var p in products)
{
Console.WriteLine("Id: {0}\nName: {1}\nPrice: {2}\nCreated: {3}\nUpdated: {4}\n",
p.Id, p.Name, p.Price, p.Created, p.Updated);
}
Console.WriteLine(new StringBuilder().Append('-', 50).AppendLine().ToString());
}
}
}
Test results:
Id: 1
Name: Product 1
Price: 12.30
Created: 29/04/2011 18:41:26
Updated: 29/04/2011 18:41:26
Id: 2
Name: Product 2
Price: 18.50
Created: 29/04/2011 18:41:28
Updated: 29/04/2011 18:41:28
Id: 1
Name: Product 1
Price: 12.30
Created: 29/04/2011 18:41:26
Updated: 29/04/2011 18:41:26
Id: 2
Name: Product 2 updated Price: 17
Created: 29/04/2011 18:41:28
Updated: 29/04/2011 18:41:29

DDD Entities making use of Services

I have an application that I'm trying to build with at least a nominally DDD-type domain model, and am struggling with a certain piece.
My entity has some business logic that uses some financial calculations and rate calculations that I currently have inside some domain services, as well as some constant values I'm putting in a value object.
I'm struggling with how to have the entity use the logic inside the domain services, or whether the logic inside those services even belongs there. This is what I have so far:
public class Ticket
{
public Ticket(int id, ConstantRates constantRates, FinancialCalculationService f, RateCalculationService r)
{
Id = id;
ConstantRates = constantRates;
FinancialCalculator = f;
RateCalculator = r;
}
private FinancialCalculationService FinancialCalculator { get; set; }
private RateCalculationService RateCalculator { get; set; }
private ConstantRates ConstantRates { get; set; }
public int Id { get; private set; }
public double ProjectedCosts { get; set; }
public double ProjectedBenefits { get; set; }
public double CalculateFinancialGain()
{
var discountRate = RateCalculator.CalculateDiscountRate(ConstantRates.Rate1, ConstantRates.Rate2,
ConstantRates.Rate3);
return FinancialCalculator.CalculateNetPresentValue(discountRate,
new[] {ProjectedCosts*-1, ProjectedBenefits});
}
}
public class ConstantRates
{
public double Rate1 { get; set; }
public double Rate2 { get; set; }
public double Rate3 { get; set; }
}
public class RateCalculationService
{
public double CalculateDiscountRate(double rate1, double rate2, double rate3 )
{
//do some jibba jabba
return 8.0;
}
}
public class FinancialCalculationService
{
public double CalculateNetPresentValue(double rate, params double[] values)
{
return Microsoft.VisualBasic.Financial.NPV(rate, ref values);
}
}
I feel like some of that calculation logic does belong in those domain services, but don't really like that I'll have to manually inject those dependencies from my Repository. Is there an alternate way that this should be modeled? Am I wrong in not liking that?
Having read the Blue Book but not really built anything in this style before, I'm looking for guidance.
EDIT
Thanks all for the feedback! Based on what I'm hearing, it sounds like my model should look more like the following. This look better?
public class Ticket
{
public Ticket(int id)
{
Id = id;
}
private ConstantRates ConstantRates { get; set; }
public int Id { get; private set; }
public double ProjectedCosts { get; set; }
public double ProjectedBenefits { get; set; }
public double FinancialGain { get; set; }
}
public class ConstantRates
{
public double Rate1 { get; set; }
public double Rate2 { get; set; }
public double Rate3 { get; set; }
}
public class FinancialGainCalculationService
{
public FinancialGainCalculationService(RateCalculationService rateCalculator,
FinancialCalculationService financialCalculator,
ConstantRateFactory rateFactory)
{
RateCalculator = rateCalculator;
FinancialCalculator = financialCalculator;
RateFactory = rateFactory;
}
private RateCalculationService RateCalculator { get; set; }
private FinancialCalculationService FinancialCalculator { get; set; }
private ConstantRateFactory RateFactory { get; set; }
public void CalculateFinancialGainFor(Ticket ticket)
{
var constantRates = RateFactory.Create();
var discountRate = RateCalculator.CalculateDiscountRate(constantRates.Rate1, constantRates.Rate2,
constantRates.Rate3);
ticket.FinancialGain = FinancialCalculator.CalculateNetPresentValue(discountRate,
new[] {ticket.ProjectedCosts*-1, ticket.ProjectedBenefits});
}
}
public class ConstantRateFactory
{
public ConstantRates Create()
{
return new ConstantRates();
}
}
public class RateCalculationService
{
public double CalculateDiscountRate(double rate1, double rate2, double rate3 )
{
//do some jibba jabba
return 8.0;
}
}
public class FinancialCalculationService
{
public double CalculateNetPresentValue(double rate, params double[] values)
{
return Microsoft.VisualBasic.Financial.NPV(rate, ref values);
}
}
The domain model ends up being fairly anemic at this point, but as I add features maybe it'll have more to it.
EDIT 2
Okay, I got some more feedback that perhaps my 'calculation' services are more like strategy objects that it's okay for my Entity to depend on. Here's another take at it with more of the logic back in the Entity, and making use of those strategy objects. Thoughts on this? Any issues with instantiating those helpers directly in the Entity? I don't think I'll want to mock those out in my tests, but OTOH I can't test the CalculateFinancialGain method without testing those strategy objects, either.
public class Ticket
{
public Ticket(int id, ConstantRates constantRates)
{
Id = id;
ConstantRates = constantRates;
}
private ConstantRates ConstantRates { get; set; }
public int Id { get; private set; }
public double ProjectedCosts { get; set; }
public double ProjectedBenefits { get; set; }
public double CalculateFinancialGain()
{
var rateCalculator = new RateCalculator();
var financeCalculator = new FinanceCalculator();
var discountRate = rateCalculator.CalculateDiscountRate(ConstantRates.Rate1, ConstantRates.Rate2,
ConstantRates.Rate3);
return financeCalculator.CalculateNetPresentValue(discountRate,
ProjectedCosts*-1,
ProjectedBenefits);
}
}
public class ConstantRates
{
public double Rate1 { get; set; }
public double Rate2 { get; set; }
public double Rate3 { get; set; }
}
public class RateCalculator
{
public double CalculateDiscountRate(double rate1, double rate2, double rate3 )
{
//do some jibba jabba
return 8.0;
}
}
public class FinanceCalculator
{
public double CalculateNetPresentValue(double rate, params double[] values)
{
return Microsoft.VisualBasic.Financial.NPV(rate, ref values);
}
}

Have your service accept the Ticket entity as a parameter. Services should be stateless and the same service should be able to provide its services to any number of entities.
In your situation I would pull the FinancialCalculatorService and RateCalculatorService out of your entity and make the methods on each service accept the Ticket entity as a parameter.
Take a second and read pg. 105 of Domain-Driven Design by Eric Evans

Given what we've seen of the classes, I don't think they're really services in the blue book sense, and I would keep the calculators in Ticket.
Neither FinancialCalculatorService or RateCalculationService has dependencies on domain entities - they both operate on primitive values. Applications shouldn't have to worry about how to calculate the financial gain that would result from a ticket, so it's valuable to encapsulate that information inside the ticket itself.
If they really don't have dependencies on domain entities, consider thinking of them as 'standalone classes' rather than 'services' (once again, in blue book terminology). It's certainly appropriate for Ticket depend on strategy objects (FinancialCalculator and RateCalculator) that do not themselves have exotic dependencies and do not themselves modify the state of domain entities.
Update for Edit 2. I think one of the advantages of making the calculators separate classes is that you can test them independently of Ticket. Strictly speaking, tickets aren't responsible for performing those calculations, they're responsible for making the right calls to those collaborating classes. So I'd be inclined to make them inject-able / mock-able as they were in your initial example.

i would say services use entities, not the other way around.
another thing, not sure on your domain, but are you certain ticket is an entity and not a value object?

You've actually struck on a question that there has been quite a bit of discussion on. There are believers on both sides of the tracks so you need to decide for yourself what makes the most sense.
Personally I don't have my entities use services as it creates a whole lot of work around the "How do I cleanly get services into my entities?" question.
It looks to me like CalculateFinancialGains() is more of a service level call. This does lead to Ticket being very anemic but I assume it has other behavior? And if it doesn't that's probably a smell...

This question is actually an example of a discussion that is in the book "Clean Code" (pp 96-97). The underlying question is whether or not to use a procedural approach or a object oriented approach. Hope I'm not in violation repeating a couple parts here, but here is what Bob Martin states for guidance:
Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.
The compliment is also true:
Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.
My understanding that a DDD "Value type" would be what Bob Martin calls a data structure.
Hope this helps and doesn't just add to the noise :)