Using LS in a DDD architecture with POCO Model Classes?

Does LightSpeed support using POCO (plain old CLR objects) Model Classes?  Also sometimes called "Code First" or "Model First" architecture?

I'm struggling a little with how to implement a POCO Domain Model within a Domain Driven Design architecture and using LightSpeed behind a generic "IRepository" interface.  Or am I missing the point of LightSpeed entirely?

Essentially, I'd like to have Model classes that have references via member variables or internal .NET Collections to other Model classes using plain old C#.  And then have those entities persisted by LightSpeed.  Similar to how NHibernate allows you to create POCO C# classes with collections, etc. and then uses the "mapping" files to know how to add/update/delete/query objects from the database.

The reason I'm asking is it's not clear to me how I can also use LS Model in a unit testing environment, where I won't be hitting an actual database behind the scenes, I'll just be setting up my POCO domain model objects with a certain state and then testing them.

Hopefully this question makes sense, I know I'm rambling!

LightSpeed fully supports "code first" / "model first."  However this is orthogonal to the POCO question -- model first refers to creating your domain model first (and building your database from this), as opposed to creating your database first (and dragging tables onto a designer a la LINQ to SQL).  We support model-first via the designer Update Database command and the migrations feature.

LightSpeed does require that your entity classes derive from Entity<T>, so they are not POCOs in that sense.  However they are still C# objects and their references to other model classes are held using standard .NET references (via EntityHolder and EntityCollection fields).

You can unit test almost all behavioural aspects (e.g. business logic) without needing to have a unit of work.  I.e. you can just new up an entity and party on it however you like -- it is just a CLR object and can exist independently of a UOW.

If you have tests where you want to put the entity into a specific state then see the Mindscape.LightSpeed.Testing namespace -- this allows you to create test entities in a specific state and modify that state.  You can also use TestUnitOfWork to mock out queries.  A real unit of work is required only if you have tests which require the traversal of associations (and I think even that can be faked using TestUnitOfWork).

Does this answer the question?

Yes, this is helpful, thank you.

So even though I can't have "true" POCO classes (meaning I don't need a reference to the LightSpeed dll to use them in other projects), I can still Unit Test their business logic without needing to spin up all the "LightSpeed stuff" like the LS Context and LS UnitOfWork ?

Is adding my own C# partial class definitions the recommended way to add business logic (properties and methods) to model classes created using the LightSpeed designer?

So if I have "Product" and "ProductPhoto" Entities created in/by the LightSpeed designer, should I add my own Product.cs and ProductPhoto.cs files to the visual studio project, as define them as partial classes?

1. Yes, with some limitations such as association traversal.

2. Yes.  One caveat is that if you need to have business logic within the getter or setter of a property defined in the designer, then you will need to set Generation to FieldOnly so that you can write your own property implementation in the partial class.  (Be sure to follow the pattern of the generated code though -- always call the Set API rather than setting the field directly!)

3. Yes.  A shortcut for creating these files is to right-click the entity and choose Refactor > Create Partial Class command.

By "association traversal" do you mean I can't access any properties of an Entity that reference another Entity in the model?  For example, I couldn't access the "Customer.Orders" property, where the Customer entity has a property named "Orders" that is an EntityCollection of Orders, pointing to the "Order" Entity in the model?

Or can I access them (add/remove objects in code) but you're saying they won't be automatically loaded for me, since there is no database on the backend to provide the related/associated objects in the PK - FK relationship?

Sorry, on re-reading my original remarks on this were very misleading!

Your second paragraph is correct.  You can work freely with entity and collection references without needing a unit of work.  However, you must be careful to use entity references rather than FK values when setting up associations.  E.g.:

Order o = new Order();
o.CustomerId = 123;  // appears to work but...
Debug.WriteLine(o.Customer);  // ...will now fail when trying to resolve the FK to an entity

Always set o.Customer. rather than o.CustomerId.

Awesome, thanks so much, you guys rock at answering support questions!