Any ASP.NET c# programers lurking?

dave82_2

Just want to have a discussion with someone about a couple of best practices regarding bussiness objects and my DAL.

Don't really want towrite out the questions if there is no one around who wants to chat LOL :beer:

craigo_2

I'm using Entity Framework for persistence, and sending / recieving data through WCF web services.

I've made a separate data mapper project to convert complex models generated by EF to simpler view models more suitable for the UI (and back).

dave82_2

Not sure my project is complex enough to warrent WCF however you might be able to answer my questions :-) probably more of an OO question than c# or .net one.

If I have a list of complex objects of the same type lets call it A. This list of objects is the data source for my GridView which is a list of search results.

Object A also contains a list of Object B as one of it's properties.

So when I perform my search the DAL reads from the database and could do one of the following :-

1. Populate only the properties required and reetunr the list of the objects
2. Return a data set and not bother instantiating the objects.
3. Create a simple Class A which is then extended by Class AFullDetail.

Hope that makes sense!

Next question is I have a list of users which have roles. I can access this in two ways via my DAL.

1. I could create a SQL view returning the user detail with every role.
2. Use two queries 1 that looks up the user and one that looks up the user role.

Again hope this makes sense!

Finally. Is it bad to store the user object in the session to avoid having to make repeat trips to the DB to pick up their roles.

Cheers Dave

craigo_2

Sure. I'm just using WCF to provide a way of exposing the same data and methods to multiple apps.

Not sure what you are using for your DAL, but suspect basic ADO? Using Linq or EF you can 'drill down' into objects properties, so if ClassA has a List of ClassBs, you could access them by "ClassA.ClassBs.ToList()" or "ClassA.ClassBs.Where(b => b.Id == [id parameter]).First()" - the first gets the whole list of A's Bs, the second just returning a single object.... and all sorts of other useful stuff like that.

I think if I was you I would create a ClassAViewModel, which is a simplified version of the database model, which could also contain a list of ClassBViewModels, also containing the properties you need. You could decide which properties to map then...

Similarly, in my current app, I have created a AuthorisationModel, containing properties I may need in the UI, as follows:

public class AuthorisationResponse
{
public string Status { get; set; }
public int UserId { get; set; }
public string UserName { get; set; }
public string FullName { get; set; }
public string LastLoginDate { get; set; }
public string Role { get; set; }
}

On attempting to login, this class is returned indicating whether it was a success, and if so, added to the session. Im not sure if this is a good way or bad way of doing it, but in my case I didnt see the point in going through all the services and dataaccess layer for something that isnt going to change once the user has logged on.

Not sure if that's a help...

Don't know if Im doing it the correct way.... just my way!

dave82_2

Sounds like your doing something very simelar to me :-)

I will take a look at the EF thanks.

That was my thinking with storing the user object in my session as well. That way I can manage security on each page without a return trip to the DB.

Dave

craigo_2

Yeh that's what I thought... just a one liner in the master page, and a redirect if the session has expired! :-).

Entity Framework / LinQ is cool cos you pretty much just drag and drop your DB from the server explorer to the designer, and if you have a well designed database all the relationships are done for you...

RobTang

dave82 wrote: »

Finally. Is it bad to store the user object in the session to avoid having to make repeat trips to the DB to pick up their roles.

Cheers Dave

Its fine for a simple single server setup, there are complications when you start load balancing or clustering.

There is also general security issues of storing anything in sessions but normally its fine.

Im not quite sure what you want for your second question (user / roles)
A list of a users roles or list with every user and their respective roles. you only really need 1 query for both anyway.

Entity Framework will encapsulate all of that for you however.

dave82_2

RobTang wrote: »

Its fine for a simple single server setup, there are complications when you start load balancing or clustering.

There is also general security issues of storing anything in sessions but normally its fine.

Im not quite sure what you want for your second question (user / roles)
A list of a users roles or list with every user and their respective roles. you only really need 1 query for both anyway.

Entity Framework will encapsulate all of that for you however.

Its a single server intrenal application so session security is not a major concern. Also it won't ever need scaled out to more than one front end so cool there. In any event I will just encapsulate returing the login in a method and I could just rewrite the part if it need to scale up.

I will explain my user roles question a bit further its a one to may relationship a user may have many roles so I can either

SELECT userid, usersDisplayName, userDept,etc FROM users WHERE username = 'adomain\auser'

followed by a

SELECT roleId, deptId FROM userRoles WHERE userid = resultFromQuery1

This returns me the usersDept etc once only

If I create a view I get that information multiple times.

so for method one I get two result sets

1,Dave,ADept,ect

1,2
2,2
3,2

for method two with a join I get 1 result set but duplication

1,Dave,ADept,ect,1,2
1,Dave,ADept,ect,2,2
1,Dave,ADept,ect,3,2

So my question was waht is more costly getting two result sets or having duplicate data?

I am guessing it depends on the number of rows returned and how many columns are duplicated.

I went for option 1 with two result sets and two bussiness objects

user

and

userRole

my user bussiness object has a property List<userRole> which is populated by the second result set.

Will look into EF tonight. To be honset its quote good for me to be writting this by had to get me back into OO design been doing SharePoint architecture for a while now so need to clear the cobwebs!

craigo_2

It might be worth starting with LinQ to SQL but Entity Framework is basically its bigger brother. I found EF has better support for working with Stored Procs, as it detects the types of the returned fields.

Great, now I know who to ask for Sharepoint help!

RobTang

craigo wrote: »

It might be worth starting with LinQ to SQL but Entity Framework is basically its bigger brother. I found EF has better support for working with Stored Procs, as it detects the types of the returned fields.

Great, now I know who to ask for Sharepoint help!

surely the point of any orm tool like EF is I dont really care about anything databasey such as stored procs.

Im sure that is the running multiple queries will be more expensive, but you can check for yourself really, just generate the execution plans in sql server management studio.

craigo_2

surely the point of any orm tool like EF is I dont really care about anything databasey such as stored procs

I agree, but I'm linking my app & DB against an existing DB that was written in the 80's and has quite complex tables. It also has pre-defined SPs that return exactly what I'm after from a single input parameter, so it's easier to use EFs function import to return these results rather than recreate the same result in C#, iysmwim...