Performance & Reporting

Topics: Developer Forum, User Forum
Aug 28, 2007 at 6:22 PM
First let me say that this is something I've been looking for, and I think you are on solid ground technically. However, I do have some questions that I've had to deal with using my own ORM and others. I apologize in advance if you've answered these question, but I got so excited by what you've produced here that I didn't read too deeply in this pass ( real work interfers :( )

Performance:
1. There are two areas where performance could be affected. The amount and ways that refelection is used. While this is not a big concern, I ask about it for completeness.
2. Database Performance is the other concern since the user is no longer in complete control. In the real world, optimizing the database is a big concern once the project starts to have many users.

Reporting:
I almost never use ORM to do reporting, but with the ORM model, I still have an intimate connection with the database. How does this work with NBusiness, especially since the database is created for you.
Coordinator
Aug 29, 2007 at 2:22 PM
Great questions, I'll try to answer them as best as possible. These are things that are sort of hard to answer in a getting started document so this is good to have it in a forum like this. The answers are, of course, more general and open to change as we see how people tend to want to use it.

Performance:
1.) Reflection is definitely heavily used by the compiler. As you build your entities it looks in other assemblies quite a bit to verify that Types exist and to find out what are the Types of parameters and such. So far it seems that the build time, even with reflection, is pretty fast and with some optimization could be faster yet so I'm not really concerned about it at this point.

But of course you're probably referring to runtime reflection because at runtime is where you really want the performance and I'm glad to say that there is virtually no runtime reflection going on at all, believe it or not. There is the occasional "is" statement or the code generated equivalent but this is pretty minor and very reasonable. There is a "Scaffolding" control that comes with the library which uses quite a bit of public reflection to do various tasks but this control is completely optional and not meant to be public facing necessarily, it is meant to be plopped into an admin portion of a site so data can be accessed fairly easily. Anyway, the reason why the reflection can be kept to a minimum is because of code generation. Typically with hand written code when you want to say, call a method and pass in each property on an object to that method then you will end up using reflection to do this. Your code might look like this:

Alternative 1
foreach(PropertyInfo p in GetType().GetProperties())
{
    DoSomething(p.GetValue(this, null));
}

Alternative 2
DoSomething(Property1);
DoSomething(Property2);
DoSomething(Property3);

Of course alternative 1 uses reflection so it's performance implications are suspect but it is FAR more maintainable and less error prone since, adding or removing or renaming a property will require alternative 2 to be altered as well. But of course this whole problem goes away when code generation comes into the picture! So in the case of NBusiness it uses alternative 2 as often as possible in place of reflection since it is "re-written" every time you build it anyway. So there is virtually no runtime reflection.

Also it's worth noting that NBusiness is a template driven code generator and that the business objects that it generates by default are merely the default templates that will get people going but there is nothing stopping you from code generating your own business objects for a more popular 3rd party business object / data access framework (CSLA, NHibernate, etc.). I would love to have more templates available, so that people have that that flexibility right away but 1 set is enough to keep me busy full time for now. Ideally this will grow as the community grows.

2.) The system I have gone with for NBusiness is to create the database schema based on the entities (or ROM, relational object mapping) vs. creating the entities based on the database shcema (or ORM, object relational mapping). BUT there is nothing forcing you to do this, this is merely a way to enable users to rapidly develop new applications. There are 3 possible scenarios I'll outline and I'll tell you how I envision them to work in the real world. Also, I should note that there is a work item for the next version posted about creating a way to generate entities based on an existing database but it has not been completed yet. To hear some more of my thoughts on this subject you can read this blog.

Database Options
  1. You can use the built-in script template and scheme updater to build your database for you based on your entity schema.
    • Pro: Very useful for rapid development.
    • Con: Not exactly realistic in a serious production environment.
    • Reality: In reality it's great for small and medium projects where you're starting from scratch. If you're building a version 2 of an NBusiness project you will be able to just continue to use the system but when it comes to deploying the changes to your production database you will need to either use a tool (Red Gates SQL compare for example) or manually write a script to merge changes into your database without losing any data.
    • After you have settled on your entities there is nothing stopping you from going into the database and optimizing it with indexes and whatnot. All of the default entities interact with the database through stored procedures and there is nothing stopping you from altering those stored procedures to be more effiecient. In that case you might end up with two scripts, one generated that gets you 90% of the way there then another that is handwritten with your various customizations and they are both deployed in turn to the production server.
  1. Completely ignore the generated scripts and schema updater
    • Pro: Complete control over your database.
    • Con: Lots of manual work, not very rapid.
    • Reality: For large projects where the developer most likely does not have control over the database anyway this will probably be the route that needs to be taken. In this case NBusiness default entities simply require certain stored procedures with specific inputs and outputs be created, a developer could manually create these stored procedures that end up interacting with any sort of underlying database schema. In this way your entities could represent a fraction of the scope of the entire database and they could represent a completely different object model. It is the responsibility of the developer to create stored procedures as the bridge between the objects and the relational model.
    • Also, I'd like to say that I have the ability to create a dynamic sql solution foremost in my mind as well. For situations where it is not possible to even create stored procedures or for people who really don't want to use them, this will be essential. This is not currently a feature and is going to be tricky but it is on the horizon. I also plan to study the new .net Entity framework stuff to see how the two might be able to live in harmony. For now it seems like it might be possible to rely on the entity framework for data-access while still using NBusiness for "Business Objects" (the differences of which are beyond the scope of this discussion probably).
  1. Custom templates
    • Pro: Even more control over how the entities interact with the database.
    • Con: Even more work.
    • Reality: In reality people probably will end up working on their own templates from time to time, NBusiness has a unique ( I think?) system of templating. It is an object oriented template system and it is possible to inherit your templates from existing templates and override key methods to selectively alter certain output as well as a "Dependency" mechanism to customize code created in dependent templates. I can go into this in more detail if needed.

Reporting:
Three solutions come to mind here though I'm not 100% on your question I must admit. Also this is assuming that you use the auto-generated database features. You could (as outlined above) use existing databases if you so choose and do reporting as you always have.

  1. Continue to write reports that interact with the database directly, if you release updates later on you'll probably have to alter your reports as well. You may find that the database that is generated from NBusiness is actually pretty simple and easy to report on.
  2. If it's possible for your preferred method of reporting to use web services as a datasource you could easily expose your entities through a webservice and report using that. There is a script called "EntityInfoTemplate" that was specifically created with webservices in mind because they are, essentially, XML serializable versions of their corresponding entities. This script is also a good example of template Dependencies, because, for example, an entity that has both the EntityInfoTemplate and the EntityBaseCollectionTemplate will have a method "GetInfoArray()" on the generated collection. You can use these info objects to pass out of a web service and use them to load entites from incoming method calls.
  3. A standard webform using databinding to bind to your objects and display the data you are looking for. Take a look at the EntityDataSource control found in the NBusiness.Data.Web namespace.

Thanks for the questions! It helps me to put words to things and hopefully it will help answer other peoples questions as they come up. And of course I love feedback and the direction of NBusiness can still be altered as discussions about these things come up, feel free to let loose with opinions and ideas.
Aug 30, 2007 at 6:54 AM
You got my questions EXACTLY right, and the answers were even more detailed than I expected, which is a pleasant suprise.

I'm pleased that once NBusiness creates the database in it's "ROM" mode, that we are free to optimize SQL Server to our hearts content(within realistic limits of course). However, your detail on the options was a refreshing concession to the realities we developers face working with different customers.

Reporting seems to be a non issue, and I need as many options there as possible(webservices are generally our preference).

Once I get some of these tasks off my plate, I will use NBusiness on a small project to get my feet wet. Good luck, and thanks for dropping this GEM into the open source community.