Our company is going through the different options for frameworks. We need the ability to modify the framework to suit our unique security needs (column level security which is implemented in stored procedures). We are considering pulling the security layer out of the stored procedures and placing it in the data access layer. Can LLBLGEN Pro handle a modification like this? How customizable extensible is the code generator? Thanks in advance.

Our company is going through the different options for frameworks. We need the ability to modify the framework to suit our unique security needs (column level security which is implemented in stored procedures). We are considering pulling the security layer out of the stored procedures and placing it in the data access layer. Can LLBLGEN Pro handle a modification like this? How customizable extensible is the code generator? Thanks in advance.

This is exactly the crossroads I was at 18 months back. The bottom line is that LLBLGenPro is perfectly suited for this task. You can use inline-templates or adjust those of LLBLGen's to insert your own security check functions at each of the class's propertie's SET/GET. In addition, LLBLGen doesn't get in your way or force you to write your own DAL and BL logic and even gives you options like using things like SelfService model that are similar to VB6 or Access programming (logic in UI). Its flexible enough that we build our own framewrok (JCL) based on CSLA.NET but with LLBLGen doing the heavy lifting for data-access and collections.

One last IMPORTANT thing LLBLGenPro will do for you. It will make devolopment FUN again and not a labourous task.

P.S: LLBLGen's classes work perfectly with VS.NET 2005 design time enhancements

Thanks, Omar!

I've to add, per-field security can be a bit cumbersome. The problem is: if user A doesn't have access rights to customer.Orders, and user B does, customer.Orders WILL be there in the class, you can't dynamically add it. The thing then is: you need some sort of safety net where you prevent A to add/see/alter customer.Orders, though for B it should be accessable.

Correct me if I'm wrong, but isn't it depending on the context in which a given Customer object is used, which properties are visible/accessable/mutable? So you can also leave it to that context's code (e.g. a webpage, BL object) to limit the access.

Furthermore, you can create IEntityValidator objects, in which you can perform validation on the entity, so you can prevent a user A saves an entity with changed fields to which A doesn't have any rights to. (however, then also the question arises: what if B did the changing of these fields, and A just saves them?)

Otis wrote:

Thanks, Omar!

I've to add, per-field security can be a bit cumbersome. The problem is: if user A doesn't have access rights to customer.Orders, and user B does, customer.Orders WILL be there in the class, you can't dynamically add it. The thing then is: you need some sort of safety net where you prevent A to add/see/alter customer.Orders, though for B it should be accessable.

Correct me if I'm wrong, but isn't it depending on the context in which a given Customer object is used, which properties are visible/accessable/mutable? So you can also leave it to that context's code (e.g. a webpage, BL object) to limit the access.

Furthermore, you can create IEntityValidator objects, in which you can perform validation on the entity, so you can prevent a user A saves an entity with changed fields to which A doesn't have any rights to. (however, then also the question arises: what if B did the changing of these fields, and A just saves them?)

Sorry about taking so long to respond. Long weekend here in the States

To answer your question, our users have very specific access to different fields of different tables. We have both row-level and column-level access, so for example, one particular user may be able to select/edit an Employee's salary, depending on a bunch of factors including whether this user is above the Employee in a certain management chain. The way we dealt with this before was by retrieving the Employee recordset from the database using a stored procedure. This stored procedure handled all security checking to make sure nothing came out of the database that the user could not see. So, to add on to the previous example of an Employee's salary being a column in the Employee table, some users can not even select the salary column, and the stored procedure would recognize this and simply select this column as <null>.

This system works very well with our current vb6 framework (a very bastardised CSLA). We are trying to build a new framework in VB.NET, and are now thinking of ways of porting our existing architecture over. One problem we've found with LLBLGEN Pro is that it doesn't appear that entities can even be built off of stored procedure calls. I am concerned that to use LLBLGEN, we would have to pull our security code out of the stored procedures and embed them in the templates...which would be somewhat time consuming and I fear would harm performance.

Do you have any recommendations on how to proceed?

mikeg22 wrote:

To answer your question, our users have very specific access to different fields of different tables. We have both row-level and column-level access, so for example, one particular user may be able to select/edit an Employee's salary, depending on a bunch of factors including whether this user is above the Employee in a certain management chain. The way we dealt with this before was by retrieving the Employee recordset from the database using a stored procedure. This stored procedure handled all security checking to make sure nothing came out of the database that the user could not see. So, to add on to the previous example of an Employee's salary being a column in the Employee table, some users can not even select the salary column, and the stored procedure would recognize this and simply select this column as <null>.

That would require some serious T-SQL statements to build the selectlist, which is not very performant in sql.

This system works very well with our current vb6 framework (a very bastardised CSLA). We are trying to build a new framework in VB.NET, and are now thinking of ways of porting our existing architecture over. One problem we've found with LLBLGEN Pro is that it doesn't appear that entities can even be built off of stored procedure calls. I am concerned that to use LLBLGEN, we would have to pull our security code out of the stored procedures and embed them in the templates...which would be somewhat time consuming and I fear would harm performance.

True. It depends though in the fact if you're willing to hold the object in memory but limit the data you're viewing or offering in an editor to be changed for example, which can be done on rules. If you're not willing to do that, so that you just want the correct data from the db, and nothing else, I'm sorry, but for now I can't help you.

Otis wrote:

mikeg22 wrote:

To answer your question, our users have very specific access to different fields of different tables. We have both row-level and column-level access, so for example, one particular user may be able to select/edit an Employee's salary, depending on a bunch of factors including whether this user is above the Employee in a certain management chain. The way we dealt with this before was by retrieving the Employee recordset from the database using a stored procedure. This stored procedure handled all security checking to make sure nothing came out of the database that the user could not see. So, to add on to the previous example of an Employee's salary being a column in the Employee table, some users can not even select the salary column, and the stored procedure would recognize this and simply select this column as <null>.

That would require some serious T-SQL statements to build the selectlist, which is not very performant in sql.

Yes, it does. There's a lot going on in those stored procedures.

This system works very well with our current vb6 framework (a very bastardised CSLA). We are trying to build a new framework in VB.NET, and are now thinking of ways of porting our existing architecture over. One problem we've found with LLBLGEN Pro is that it doesn't appear that entities can even be built off of stored procedure calls. I am concerned that to use LLBLGEN, we would have to pull our security code out of the stored procedures and embed them in the templates...which would be somewhat time consuming and I fear would harm performance.

True. It depends though in the fact if you're willing to hold the object in memory but limit the data you're viewing or offering in an editor to be changed for example, which can be done on rules. If you're not willing to do that, so that you just want the correct data from the db, and nothing else, I'm sorry, but for now I can't help you.

I think we would be willing to hold the object in memory and then perform security on it, if we can do this without a ton of extra complexity. Another potential issue is that a lot of the fields we bring back are calculated, and I don't mean something like A+B, but more along the lines of calculations done off of joined views and temp tables (all done in the stored procedures). As far as you know, is it difficult to do this kind of thing from outside of the database, using I suppose ADO.NET?

mikeg22 wrote:

This system works very well with our current vb6 framework (a very bastardised CSLA). We are trying to build a new framework in VB.NET, and are now thinking of ways of porting our existing architecture over. One problem we've found with LLBLGEN Pro is that it doesn't appear that entities can even be built off of stored procedure calls. I am concerned that to use LLBLGEN, we would have to pull our security code out of the stored procedures and embed them in the templates...which would be somewhat time consuming and I fear would harm performance.

True. It depends though in the fact if you're willing to hold the object in memory but limit the data you're viewing or offering in an editor to be changed for example, which can be done on rules. If you're not willing to do that, so that you just want the correct data from the db, and nothing else, I'm sorry, but for now I can't help you.

I think we would be willing to hold the object in memory and then perform security on it, if we can do this without a ton of extra complexity. Another potential issue is that a lot of the fields we bring back are calculated, and I don't mean something like A+B, but more along the lines of calculations done off of joined views and temp tables (all done in the stored procedures). As far as you know, is it difficult to do this kind of thing from outside of the database, using I suppose ADO.NET?

That will become perhaps less performant, if the calculations are on sets, for example. Especially if you use temptables, it can be hard to reproduce it in C#/VB.NET code and be performant.

to keep the forum guideline removed question & created a new thread.