In NHibernate there is a Save(entityObject) method, which creates a new row in the database with the given entity object, also, has an Update(entityObject) which updates the row corresponding to the entity object with the property values of this object. It also has a SaveOrUpdate(entityObject) method, which checks the whether the entity object corresponds to an existing row in the database, and chooses whether to call Save(…) or Update(…) based on that.
The way I usually do web applications across multiple tiers, when not using view models specifically, makes me encapsulate much code in Services layer that sometimes does not need to care about whether the given entity is persisted in database or not. Thus wanted to have similar method using Entity Framework as ORM.
Of course I have implemented the method number of times and the code evolved based on which version of Entity Framework I’m coding against, and my knowledge of the framework internals as well. Actually, when you work with so many ORMs like I did, a new ORM or ORM version turns to only sound like “What’s new in the manual?” thing.
The method is implemented as an extension method to the ObjectContext class to call it on any context instance. Also, no namespace is there so that it’s available without having to add any using namespace … statement to fine it available.
Also, toy notice the method does NOT call context.SaveChanges(). This is on purpose so that the calling code is still in control when to submit the context changes, and makes the method similar in effect to other ObjectContext methods.
The Calling Code
A sample calling code to this method would be similar to below. This is not the code I used when testing it but the easiest to understand, as most people know the repository pattern already. Also, in many places there have been over-simplifications on purpose (no extra base classes or DI containers etc..)), but this is to serve the sample clarity purpose solely.
I’m assuming you have checked the walkthrough already, but if not, it’s enough to know that Book is a class that represents an entity, and BookCatalog is a class that inherits ObjectContext.
This method is not special at all. I just noticed that I have not posted code into my blog for very long, and wanted to change this by creating something as small as this one, hopefully to be followed by more advanced stuff that I should be taking out from my internal helper/toolkit libraries. I have stuff related to Entity Framework, NHibernate, Spark, ASP.NET, and others, but those are to come at another time…
If you are eager loading Products for example in a typical (Categories 1<->* Products) relation, the standard syntax would like:
What is the problem with that?
The “Products” part. The word “Products” is a string. If I rename the Products table to ShopProducts or whatever or even remove it from this data diagram and have it elsewhere, or even something wrong happens and the relation is removed from DB/diagram by mistake, my code will still compile, but will fail when it runs. This is BAD BAD BAD.
How to solve this?
Since I always believe that if something exists somewhere you shouldn’t do it yourself unless its totally broken (and I mean REALLY REALLY BROKEN), I started searching inside the Entity Framework itself for something to get the entity name from.
At first it seemed super easy. Every entity class has a static property “EntityKeyPropertyName”, so, I thought I can write something like:
DbDataContext.Categories.Include(Product.EntityKeyPropertyName); // But this didn’t work
Where Product is the entity class generated for table “Products”. Note that singularizing the name (Products becomes Product) does not happen automatically like in Linq-To Sql, you’ll have to change it manually, which is not required for the code here of course.
As you an see n the comment, this didn’t work. The value of property was always “-EntityKey-”, the default value of the abstract class “StructuralObject” which all entity classes inherit.
I kept searching all over until I found that the only place I can get the name from was an Attribute generated on the class somewhat like this:
My requirement was simple. if the diagram has something wrong that the relation between ParentTable and ChildTable tables but not about the entity classes themselves, My code should not still compile and fail on run. I need to use some code that depends on the relation so that if something is wrong with the relation this code fails early and I know about it the problem the next time I build the VS project.
The Final Solution
I tried badly to get the entity name from the API, after frustration, I ended up writing this code:
For things like: Order.Customer.Address (multiple levels), you’ll have to write code like:
DbDataContext.Orders.Include( order => order.Customer ).Include( customer => Customer.Address );
What’s Eager Loading? (in case you don’t know)
Let’s say you have tables Products, and Categories with relation 1<->* between them (Any category has many products; one product has one category). Let’s say you want to display a page of all products grouped by categories. Something like the following list but with much more information of course:
If you are using some ORM / Code generator that creates for you classes like “Product”, “Category” and gives you properties like “myCategory.Products” , “myProduct.Category”, how would you create such page?
Normally you’ll put a repeater or such for products inside a repeater for categories.
The products repeater will have its data source set to the current category item of the Categories repeater, something like “( (CategoryEntity)Container.DataItem ).Products”. Fine with that? Familiar?
OK. Now, if the code generator that generated the “Products” property has something like that:
public List<PRoduct> _Products;
public List<PRoduct> Products
if (_Products == null)
_Products = (from products in DB.Products
where products.CategoryID == this.ID
Nevermind the LINQ syntax. It’s just like writing “SELECT * FROM [Products] WHERE …” with all the dataset/datareader stuff.
Lazy Loading (AKA. Deferred Loading)
If the generated code (or your code) looks like this, this means that that for every category in the database, you’ll have a separate DB call to get the products of this category.
It also means that the products of each category will not be loaded until someone writes code that calls the getter of the Products property. That’s why this style of coding (not loading the related objects until they’re asked to be loaded) is called Lazy Loading.
This is good for a single category where you may be seeking just the basic information of the category and will not try to load products, since then they will not be requested when you don’t ask for it.
However, this is very bad for our example page. Because it means that a new DB call for each category. Imagine that you have 20 or 50 or 100 Category there, this will give you how many DB calls? (Hint: N Categories + 1 call for the category list itself).
What if the code in the getter above was in the constructor?. Imaging something like:
public Category(int categoryID)
// Code that laods category info from DB. Does not matter here.
//Could be in factory method or such. Not our topic
_CategoryID = categoryID;
// …. …. …. Continue Loading Logic
//The important part
_Products = (from products in DB.Products
where products.CategoryID == this.ID
This is good in case you know that in every situation when you use the category, the Products will be needed. This is probably not useful in a Product/category Scenario but think of a Person table and Address table where most likely whenever you load a Person you’re going to load his Addresses.
This is also useful especially when using ORM/code generator as in the first example. Lets get back to the Repeater example. If you use Entity framework or similar ORM, and you set the Categories query to load the Products eager loading (meaning each Category is created with its Products loaded already), Entity Framework can have a single connection and only TWO database hits, one for the Categories, and one for the Products. This is very useful in many listing scenarios. It also help especially when you have many parent objects (say Categories) or if the parent object needs to load entities of many different classes (say User needs to load Roles and Permissions and Personal Information and History and …. (if such case is applicable for you of course.
Now that you know what eager loading is, you can go up and check how the Entity Framework does that.
This post has taken so long to be started in writing. I’ve been busy with many events in my life lately. Suffering from frequent limited internet access lately, and, all this moving between companies thing has been eating me. And yes, I admit, I’ have been as tired and more honestly lazy as you expected me to be!
Hey, there’s a little warning. This post is not exactly for my usual audience. I’m sorry, but introducing Domain Driven Design is not one of the goals for this post. There’re many interesting resources and books (even FREE: InfoQ, Domain Driven Design Quickly) on the topic. However, if you leave me a comment telling me to make a write-up on the topic, of course I will :) :).
One more thing. Another reason I’m working on this is that I’m preparing for an internal session here in Raya about Practical Lightweight Domain Driven Design. This session is truly internal yet. It should be recorded though but I’m not sure whether it’ll be possible to publish the videos (Yeah, I will see how we can have our public sessions of possible sure!). If you have a user group and would like me to give this session in a group meeting, I’ll be glad to do.
For now, we’re going towards LLBLGen Pro 2.6 for DAL generation and such (using Self-Serving mode probably). Yes, we’re going for database first design, and not using NHibrernate. I’m hoping that we can keep those two issues for other threads :).
Right now, I’m going for other Domain Driven practices. I want to make sure using POCO classes is worth it, and then see how to have those in LLBLGen (which -LLBLGen main template- is in its internal not much different design than Active Record, which in many times is handy, it’s VERY rare t change DAL when one fits different DB providers with good performance), and what are common patterns to do Domain Driven Design at all when having LLBLGen as DAL (if it makes any difference – again: and if effort to make it encapsulated enough to make no difference is worth it).
Making this choice alone is worth its own article. Maybe should title it “In Search For The Perfect ORM” as well :-D.
So, is anybody here doing DDD and uses LLBLGen as DAL generator ?How does the experience look like ? What are common practices across all projects and what have been pitfalls ? etc… These are the kinds of questions I’d love to see somebody here with something to share about.
Domain Driven Design At Work
This is not really an LLBLGen issue. It is questioning the Domain Driven Design productivity itself. I like DDD. I see it as the natural next step after 3-tier deisgn. This whole separation of concerns, models, repositories, factories, infrastructure, and services paradigm just fits my mentality and view of how the world looks like. However, not all the practices in DDD are similar in terms of return of investment, the customer business value that Agile emphasizes. The trick is to know which are and which aren’t, and how to do the balance.
In the second message, I go through an example of typical usage for DDD that has tried just a little bit to be lightweight in some areas but not others, and my own overview about what needs improvement:
I’ve been on a project that leverages DDD once before myself. The project has been frozen for a while for other priorities, etc…Maybe I start with my own take on the subject!!
We’ve been using the “Adapter” model. I thought it was for seeking some sort of more control/flexibility. Reading Fran Bouma’s blog (http://weblogs.asp.net/fbouma, the creator of LLBLGen), I see how he’s so much of an “Entity Design” guy. Well, makes sense, he owns the best entity design I’ve seen so far having considered EF and CSLA.
Clearly he sees the “Self Servicing” as the core for entity design rather than model design. You know, the “entity.Save();” style. This makes me have two thoughts at a time actually. 1- That “Adapter” model is the right choice for DDD (I’ll get to that just below), 2- That maybe DDD fully is not what I really want (the entity Self Servicing style is so powerful. It has saved my day so many times before).
Looking at the project I’ve been working on, We had something like those namespaces / VS projects (and others … ):
Company.Project.Adt (for models that may be reused in other projects, like Language, Currency, …)
Company.Project.Model (for project business domain specific models)
Company.Project.Data (for LLBLGen stuff, we have also “DataDBSpecific” and such related to Adapter mode)
Company.Project.Repositories (have interfaces and implementations for repositories, let’s put aside why the two in one project for now)
A repository load method could probably look like:
What I want to highlight here is the “include…”, “load…” parameters. I’m not sure whether this is the best way to do it.
Also, what really hits me is the mapping. You know, from LLBLGen entities to our domain models. We have been doing this in factories which live in the Repository space. Each factory had methods similar to this:
Regardless of the “public” access modifier (this is all very well hidden behind a service layer, but let’s put the whole issue aside as well), the idea of having to go through all the mapping has been just a boring ugly task, that has been there for long.
To be honest, we didn’t get so much benefit of it. It should have good promises, but how good compared to the cost of implementing them for complex object graphs ? That is the question!
Things got just worse when we wanted to implement our service layer. That’s a service in the classic sense of “web” service layer (REST), we wanted to created DTOs that can correspond to XML and JSON responses of our choice, and again, we had to do the mapping from and to the domain models and DTOs. Want more ? The DTOs wouldn’t convert to XML strings automatically (to JSON it would), we had to have another mapping layer from and to the DTOs and the actual XML.
Of course we had much time defining XML specifications and writing so many unit tests for this. I know not every project can go in this direction to this extent, but, I wanted to show where going in this path can take you.
So, even without service layer complications. You still have the model mapping tasks that (and this is what worries me) in many situations does not correspond to a “business” need. Note that I want to be doing Agile as well, and this makes the issue of delivering business value a true concern.
You can talk about automated generation for mapping. This may be something. We know it’ll not be this direct or one to one of course anyway, but it may help.
Would you do Domain Driven Design with “entity” models assuming the developers will stick to calling the repository’s “Persist” method instead of “entity.Save();”? You just can’t do that! How about new developers ? How about inconsistencies ?
Is mapping really that bad and much of an effort ? First look at it, I say it isn’t. But given complex scenarios I’ve been though I have to wonder about things like “complex object graph” and “caching” (in memory, on different levels, etc…).
It’s all about trying to calculate the costs indeed.
That’s what I’m trying to make out of this, the trick for the right cost.
Conclusion: How About YOU ??
Let me repeat the end of those messages:
Anyway, would love to hear your takes and what you have :) :) :).
If you have any thought on the topic, those will be most appreciated. You can comment here or in the topic messages page on ALT.NET Yahoo Group. This is an open discussion area, and I do not expect it to be closed soon.
Same, if you want to hear more ramblings on the topic, or just want me to shut it up all, send me a line.
Would love to see what others have to say about this….