According to this article:
http://subsonicproject.com/docs/3.0_Migrations
Bottom line: if you're a developer that is concerned about database design,
migrations might not be for you.
Ok, that's fine, I can treat the database as simply a persistent repository of data that doesn't contain any business logic. In other words, a glorified text file.
What I don't know how to do is relate two objects together. Take for example these two classes:
public class Disaster
{
public int DisasterId { get; set; }
public string Name { get; set; }
public DateTime? Date { get; set; }
public IList<Address> Addresses { get; set; }
}
public class Address
{
public int AddressId { get; set; }
public string WholeAddressHereForSakeOfBrevity { get; set; }
}
Disaster contains an IList of multiple Addresses that were hit by the disaster. When I use SimpleRepository to add these to the database with SimpleRepositoryOptions.RunMigrations, it generates the tables with all the columns, but no foreign key columns as expected.
How would I relate these two together so that when I call Disaster.Addresses, I get a list of all the affected Addresses? Is this possible or do I have to use ActiveRecord instead and create the database tables first? Or do I have to add in a column for the disaster's ID into Address? If so, how does this method work for many-to-many relationships?
It's possible - you just do it by hand is all. Add a property to Disaster called "Addresses" and make it an IList<> (or you can make it IQueryable if you want it to Lazy Load). When you retrieve your Disaster, just be sure to retrieve your Addresses.
It's sort of "manual" - but that's the idea. I'm working on enhancements to this that i'm hoping to push in a later release.
And before you ask why I didn't do it in the first place :) it's because I don't know if I should use a Many to Many or 1-many based on the parent/child relationship. In your example, I'd guess that it's probably 1 to many but given what I know about Addresses and disasters (especially in Florida) it should probably be many to many.
Bottom Line - how would SubSonic know this? We could introspect both objects for "bi-directionality", which means if Address has many disasters than it's many to many (which is obvious) - but then that's not happy coding if you like DDD.
I'm leaning towards that rule with some type of override that would force the issue. Your thoughts on this are welcome :)
Related
I know this has been asked to some degree already - and is a fairly subjective question. I’m trying to figure out the best naming convention for a set of services that we are porting over to ServiceStack from WCF. I have read through a lot of the ServiceStack documentation and examples – and I feel I have a pretty good understanding of the overall structure. What I am trying to work out is the best naming convention for my request and response DTO’s.
Let me give some examples. Here would be my request dto as I have currently named it.
[Route("/blast/emailblast", "POST")]
public class CreateEmailBlast : IReturn<CreateCreateEmailBlastResponse>
{
public Guid SenderProfileId { get; set; }
public Guid TemplateId { get; set; }
public string CallListName { get; set; }
public string CallListCategory { get; set; }
}
public class CreateEmailBlastResponse : ICreateEmailBlastResponse
{
public string ResponseMessage { get; set; }
}
So the naming I have adopted is prefix the dto with "Create" for posts, "Get" for Gets, etc... Would it be wiser to just use EmailBlast and EmailBlastResponse? Just wondering if anyone has some input on these two different methods of naming.
I think it will be wiser to use EmailBlast only. As, http verbs are there to identify what is going to happen.
If you are looking at how to design good API. (General purpose, not specifically with SS). There is a wonderful video over infoq. I couldn't remember the name over top of mind.
But gist of the that presentation was , try to think of API as user facing html page. What you need at user end. And I can go a little bit more to that, define model after deciding page. To do specifically that, there is a need of metadata.
Means, there is a EmailBlast model, how can I tell to create. So, instead of CreateEmailBlast model, I will go with http post verb. Here, I am trying to take simple example.
Personally I will try to avoid Hungarian notation for variable as well as for model wherever I can.
Please let me know if I understand you question correctly and also if you need any further details from my end.
I'm trying to model a business domain that produces stock that actually has a complex recursive stock system.
Stock can be uniquely labeled at the item level, or;
Stock can be uniquely labeled at the box level (containing a number of un-identifyable items), or;
Stock can be labelled at the pallet level (containing a number of un-identifyable boxes), or;
Stock can be labelled uniquely and then contained within levels above, i.e. unique items in a unique box. Or unique items directly placed on a unique pallet.
Here is what I was thinking, however I'm not sure about the "QuantityOfUnidetifyableInners", but I don't know any better way to model a system that may or may not uniquely identify it's entities, so any advice on that woud be appreciated, or if anyone can see an alternative approach to the problem.
/// <summary>
/// ValueObject
/// </summary>
public sealed class StockIdentity
{
private readonly string _serial;
public StockIdentity(string serial)
{
_serial = serial;
}
public string Serial { get { return _serial; } }
//...equals contract
}
/// <summary>
/// Entity
/// </summary>
public sealed class StockItem
{
public StockIdentity Id { get; set; }
public int QuantityOfNonIdentifiableInners { get; set; }
public StockItem[] Identifiable { get; set; }
}
Here is an idea: why do you need this quantity? Is it even necessary in your domain model, or is it just something that belongs in your read model?
If it is, I would assume that the quantity is something you need to verify whether all the items are still there, so i would assume you would call it something like
ItemCount
I assume domain experts do not say something like "Hey, for every label we have a quantity of non identifiable inners", but probably something like "later on, we count the items to make sure everything is there".
Domain experts tend to be very - even too much - aware of the things they say when they know their words will be used as a baseline to implement software, so they tend to speak more formal.
The minute you ask a side question, they usually stop caring about their formal language, and then they start speaking their "true" domain language; it happens in a very subtle way, and it is sometimes hard to notice, but that is usually the part where the value is.
YMMV.
I'm developing an application using domain driven design. One of the patterns I've been using is Repository pattern. For the sake of simplicity, let's say I have following classes and interfaces.
Car - domain class representing car domain concept.
public class Car {
public int Id {get;private set;}
public string SomeUniqueCode {get;private set;}
}
ICarRepository - interface for adding, deleting or saving changes to Car objects.
public interface ICarRepository{
Car AddCar(Car c);
void DeleteCar(Car c);
}
My problem is, how to check uniqueness of SomeUniqueCode property among all Car objects in the database? That property is changed by user (not auto-generated) at any time during the object life-cycle. Of course, one solution would be to put the unique key in the database, but that is not the principle of DDD. I've seen Specification pattern used to validate single objects. How would that pattern be applied to a set of Car objects?
Is it legitimate that Specification class (let's call it CheckUniqueCarSpecification) accesses ICarRepository?
A repository mimics an in-memory collection. What I have used before is a Contains method as opposed to a Find method, I guess you could have either. A query layer could also be used for this. Just as you have a CarRepository you could have a CarQuery. Trying to check for uniqueness in the domain is somewhat pesky. I would do a check for the sake of convenience but still rely on the DB to raise the exception since you should also handle that case. Using the specification pattern for this may be more effort than it is worth.
Since repository is a 'collection' I wouldn't have Commit and Rollback on there.
Use DomainService ICarCodesLibrary.
public class Car {
ctor(string someUniqueCode, ICarCodesLibrary codes)
{
// the check
codes.IsValidCode(someUniqueCode)
}
public int Id {get;private set;}
public string SomeUniqueCode {get;private set;}
}
Implement the interface in the place where u create the Car object and inject it. Also get rid of the properties and use fields. The ID is OK to be a prop.
I've just started with Domain Driven Design and trying to apply it for my current project.
I've started with a pure domain model and now stuck with my Data Access layer. I have a completely home made data access layer therefore no any of well known ORM tools can be applied here.
I cannot figure out how to deal with updates. Let's say I have the following Objects:
public class Document : Entity
{
public IPropertiesCollection Properties { get; set; }
public IContents Contents { get; set; }
}
public class PostalDocumentsPackage : Entity
{
public String Name { get; set; }
public DateTime DeliverDate { get; set; }
public ICollection<Document> Documents { get; set; }
}
I have corresponding repositories IDocumentsRepository and IPostalDocumentPackagesRepository for retrieving objects (for now).
The problem I deal with now is to situation when i want to add a new document do Documents collection of PostalDocumentsPackage. Basically I see two possible cases here:
1) Implement the collection that track changes in original collection and holds lists of items that were updated\removed.
2) Implement separate methods in repository for adding documents to the package.
I wonder are these approaches is ok or can cause problems in future? or there is another alternatives?
Typically change tracking would be handled by an ORM such as NHibernate. In your case you may be able to do the following:
Select new documents based on the value of the identity property.
Issue a SQL delete statement before re-inserting into the table.
A problem with either approach is that the documents collection may be big, such that loading all documents for each PostalDocumentsPackage may be a bottleneck. Also you must consider whether you need change tracking on the Document entity in addition to the documents collection. If so, then you would need to implement change tracking for the Document class as well. Given that you're not using an ORM I would suggest solution #2 since solution #1 will lead you down a path of re-implementing change tracking, which among other things would pollute your domain classes. You may also consider a CQRS/Event Sourcing architecture in which change tracking is made explicit.
The shorter version of the Question: "Is it ok to have a superclass, with 2 subclasses, one is an entity the other is a Value Object?"
To longer version:
T have a Team superclass. The Team has the Master, Helpers and a Code.
Then i have the DefaultTeam, subclass of Team, which is an entity with an unique **Code**** has its domain identity.
Then i have the **ExecutionTeam, its a subclass of Team and has an extra attribute OriginalTeam:
public abstract class Team{
public string Code{ get; protected set; }
public Worker Master{ get; protected set; }
public IList<Worker > Helpers { get; protected set; }
...
}
public class DefaultTeam: Team
{
}
public class ExecutionTeam : Team
{
public virtual string Code { get { return OriginalTeam.Code; } }
public virtual DefaultTeam OriginalTeam { get; private set; }
...
}
The ExecutionTeam, is the team that executes a Task.
When a Task needs to be executed, we choose a DefaultTeam to execute it.
But we can change the Helpers from the DefaultTeam (the master never changes).
That team that executes the task, is a variation of the DefaultTeam (OriginalTeam), but with the Helpers that were chosen just for that Task.
The ExecutionTeam will have the same code has the OriginalTeam. So the ExecutionTeam has no unique identity.
If there are 10 executions of tasks by the same DefaultTeam, there will be 10 ExecutionTeams with the same code (with the same OriginalTeam). So ExecutionTeam is cannot be an Entity.
But having an Entity and a Value Object sharing the same superclass (both being Teams), is a bit strange. Maybe this domain model has something wrong.
Need opinions.
Thanks
What is it that makes the DefaultTeam a Value Object rather than an Entity? Isn't a DefaultTeam also an entity?
That being said, here are some comments:
Why do you need a special class for DefaultTeam? Can't a DefaultTeam simply be an ExecutionTeam, with certain specified values?
A DefaultTeam should probably be an instance of a Team that is associated with an application domain. For example, you might have a particular team that is generally used to solve problems with Project XYZ.
Instead of listing "DefaultTeam" as a property of the ExecutionTeam, you should probably have a "PreviousTeam" as a property of both the Team and ExecutionTeam classes.
This will be more generalizable, in case the team gets changed yet again.
Since Task is an important part of the domain and is assigned to a Team, it should probably be a property of Team.
"Helpers" doesn't seem an appropriate name for the team members. Why not just name them "Members" or "TeamMembers"?
"Master" is probably un-PC unless you are working in Dilbert land or dealing with a database :) You might want to change this to "Supervisor" or "Manager".
"Code" is probably a bad name in the context of your application, as it may easily be confused with programming code. You might want to use "Id" or "TeamId" instead.
Sounds like ExecutionTeam might be better modeled as an interface ICanExecuteTasks. Would that work for you? It would eliminate the issue you are struggling with..
As to your short question, if the ExecutionTeam was indeed a derived class of Team, (inheriting from team and representing an "IsA" relatoonship, then the answer is No, they cannot be of different types because of course, every ExecutionTeam isA Team, thgere is only one thing, which is both a Team and an ExecutionTeam at the same time... It cannot be both an entity Type and a value type at the same time.
But the way you have designed the classes, as you have structured things, ExcecutionTeam is not a derived class, it is a property of the DefaultTeam. This implies that they have a "HasA" relationship. THis implies that they are different, co-existing objects, one of which can be an entity and one of which can be a value type. But my gut tells me this is not an accurate mirror of your real domain model...