pipelineconsulting
asked on
Entity Framework and Business Logic
I am a bit confused by the Entity Framework, to which I am new.
I am currently writing a web business application in .NET which is running from a standard SQL database. It is quite a complicated database and has around 60 tables, of which 40 contain "proper" data and the remainder are intermediate tables used for relationships and so on. It also has stored procedures for doing anything that needs doing to the database (updates, inserts etc.).
Doing anything like this, I would normally start off with a DAL based on a DataSet and put in all the relevant tables from the database and the relationships etc. I would then code a business logic layer which taps into the DAL. Depending on what kind of app it is, I would then have a cache layer which is identical in structure to the BLL - this cache layer is using SQL cache dependencies. My application then interrogates the cache layer which sets things off down the cache/BLL/DAL/database chain.
I have started to code a set of business objects for use in the app. For each kind of object (e.g. a customer) there are actually two classes - a class representing the business object itself (e.g. for a customer, this is where the name, address and so on are contained). The second class is a collection which contains items for the object (e.g. a customers collection populated by customers).
Relationships are built into the business object class, so a customer class has a "orders collection" property and so on. The business object class also contains some more complicated logic, so for an order object class, there may well be methods that raise invoices and so on.
Having got so far, this is fast becoming tedious and unwieldly. For this reason I was taking an interest in Entity Framework but I am unsure as to how to proceed with this.
1. Does the entity framework simply replace my DataSet DAL?
2. If so, where does my business logic (e.g. checking fields before sending to the DB) appear?
3. At the moment, the DAL has methods based on stored procedures - how can I maintain this kind of approach? I want as much data access code in stored procedures as possible and not be querying the database using LINQ in my app classes.
4. Where can I put the more complicated methods that I might have in my business objects?
5. How do I cache the data?
6. What is a POCO and how does this fit into the layering?
Ideally, I want to be in a situation where my UI layer can use nice, friendly, strongly-typed objects and avoid LINQ wherever possible.
Just to throw a potential spanner in the works, I am using VB not C#...
I am currently writing a web business application in .NET which is running from a standard SQL database. It is quite a complicated database and has around 60 tables, of which 40 contain "proper" data and the remainder are intermediate tables used for relationships and so on. It also has stored procedures for doing anything that needs doing to the database (updates, inserts etc.).
Doing anything like this, I would normally start off with a DAL based on a DataSet and put in all the relevant tables from the database and the relationships etc. I would then code a business logic layer which taps into the DAL. Depending on what kind of app it is, I would then have a cache layer which is identical in structure to the BLL - this cache layer is using SQL cache dependencies. My application then interrogates the cache layer which sets things off down the cache/BLL/DAL/database chain.
I have started to code a set of business objects for use in the app. For each kind of object (e.g. a customer) there are actually two classes - a class representing the business object itself (e.g. for a customer, this is where the name, address and so on are contained). The second class is a collection which contains items for the object (e.g. a customers collection populated by customers).
Relationships are built into the business object class, so a customer class has a "orders collection" property and so on. The business object class also contains some more complicated logic, so for an order object class, there may well be methods that raise invoices and so on.
Having got so far, this is fast becoming tedious and unwieldly. For this reason I was taking an interest in Entity Framework but I am unsure as to how to proceed with this.
1. Does the entity framework simply replace my DataSet DAL?
2. If so, where does my business logic (e.g. checking fields before sending to the DB) appear?
3. At the moment, the DAL has methods based on stored procedures - how can I maintain this kind of approach? I want as much data access code in stored procedures as possible and not be querying the database using LINQ in my app classes.
4. Where can I put the more complicated methods that I might have in my business objects?
5. How do I cache the data?
6. What is a POCO and how does this fit into the layering?
Ideally, I want to be in a situation where my UI layer can use nice, friendly, strongly-typed objects and avoid LINQ wherever possible.
Just to throw a potential spanner in the works, I am using VB not C#...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.