We learned how to add custom fields to BO but we think that it is more efficient to do this at runtime.



We are planning to generate our reports and there are more than 100 reports to be generated. If we create a new custom BBS and custom BO for each report (this is the case in Strataflix) then this will not be a dynamic process and it will take lots of time to do it, we can say that it is not efficient as a summary.



Is it possible to add custome fields to BO at Runtime so that we can dynamically modify a custom BO at runtime depending on the nature of the report?



Best Regards

Could you give a specific example of what the application of this would look like? I'm understanding the basic idea you are requesting but, unless I'm missing something, I believe the realities of making this work would be much more complicated than the abstract explanation would suggest.

For example, "changing a report at run-time" has all kinds of repercussions. The queries and logic involed with pulling the data from the database efficiently, the way the data gets populated and further modified in the BO, the way it is pulled and shown on the report, etc.

Again, I understand the point of the excersize. Generating reports, by their nature, involves some busy-work and you are trying to avoid that. However, for me, this isn't something where further automation would pay dividends. Obviously, your needs may differ, but the StrataFlix example is a result of our own examinations of how much we could resonably automate versus how much would require developer intervention, and what you see there is effectively where we landed.

For perspective, we also have more than 100 reports in our medical application (108 at the moment, with that number growing every version), but we have followed basically the same process you see in the StrataFlix reports for each one.  Using the custom BBS, you get to inherent all of the basic BO logic, and only have to account for the custom logic that is necessary for each report. Yes, you have to code any custom properties to accomodate the custom logic required by a given report. However, you are going to have to code those custom properties regardless of whether you do it in the development environment, or through some mechanism at runtime.

It would be better if there was a mechanism which can automatically add the required properties (since the tables and its relations can be given as a parameter) to a custom BO at runtime.

Let me explain it more clearly.

We are already storing the table fields and their relationships in our database. A class method can take three parameters, an array of tables, an array of the fields that are going to be displayed and the name of a stored procedure. By using the already stored relationship information, our object can automatically figure out which fields should be added to BO and it can automatically add these fields, execute the stored procedure and connect the resulting BO to the custom BBS that can be used for a grid or a report. We would like to write this method but we dont know how to create the BO properties at runtime.

Wouldnt it be simpler to just call this method instead of creating a number of custom BBS and custom BO and adding each one to the project manually?

I'm sorry, but I'm still missing some of the detail. I can be a bit slow at times .

Could you give a specific example? I.e. "we have two tables, Customer and Employee, with fields x, y, and z. We want to provide parameter Q and have it spit out a BO containing a, b, and c." 

In short, I don't think we have the capability to do exactly what you are looking for currently in the framework, but that is because, to my knowledge, we haven't run accross a definate need for it. Most requirements that hit around this are covered by (manually programmed) custom properties, pseudo BOs, views, or (if you are more worried with development speed than best practices) the ability to directly reference custom columns in a returned datatable (i.e. MyBO.CurrentRow["myColumn"]).

As far as automating the reporting process further, Edhy and Trent have been having a good discussion around possibilities there, and planned future development for StrataFrame in this thread. You may browse through it real quick to see if any of the ideas or points there are hitting home with what you are trying to do.

I may be completely off base here but if this is just for reporting and you are using something like Report Sharpshooter (and probably with crystal as well ) the trick might be to just not use SF business objects to assemble the data for the report.



Linq or SQL stored procs should be able to assemble the data you need into a datatable or tables in a dataset and you could just feed your reports from that. SF doesnt require you use business objects. The reporting could be handled without using them as all. I think trying to dynamically create BOs which are strongly typed ( and compiled ) at run time seems like that hard way to go about what you are trying to do.