none
Help required in architecting an application RRS feed

  • Question

  • Hi Everyone ,

    The proposed architecture of  our new application is as given below

    1. Presentation Layer
      This will be an ASP.NET MVC  application running on mobile
    2. Services Layer
      This will be a WCF Services . The Presentation layer communicates with the services using custom DTO.
    3. Business Logic Layer
      this is a normal c# class library where all the businnes related logic are written. This  layer exposes Business objects to the services layer. The services layer uses an entity translator to convert Business objects in to DTOs
    4. Database Access Layer
      We are plannning to EF4.1 for this. We would like to have stored procedure support. Hence the plan is to use Model First approach

    This being our architecture , i have the following doubts

    1. Instead of having  Business Objects and Entities seperately , can we combine these two. Is it a good approach ??
    2. Since the client is web based , is it Ok to use Self tracking entities ??
    3. Could be send me some links on how to optimize peformance

    Regards
    Sabarish

     

     

    Wednesday, June 22, 2011 10:34 AM

Answers

  • On 6/22/2011 6:34 AM, sabarish_s wrote:
    > Hi Everyone ,
    >
    > The proposed architecture of our new application is as given below
    >
    >    1. *Presentation Layer*
    >       This will be an ASP.NET MVC application running on mobile
    >    2. *Services Layer*
    >       This will be a WCF Services . The Presentation layer communicates
    >       with the services using custom DTO.
    >    3. *Business Logic Layer*
    >       this is a normal c# class library where all the businnes related
    >       logic are written. This layer exposes Business objects to the
    >       services layer. The services layer uses an entity translator to
    >       convert Business objects in to DTOs
             That's called a 'mapper'.
     
    >    4. *Database Access Layer
    >       *We are plannning to EF4.1 for this. We would like to have stored
    >       procedure support. Hence the plan is to use Model First approach
     
    Yeah you can use sproc as needed using the EF model. You can do the
    queries using Linq-2-Entities, and on the other hand, you can use sprocs
    for ADD, Update and Delete used by the EF model.
     You can either bring the EF entity to the BLL from the DAL or use DTO(s)
    between the BLL and DAL using a mapper too.
     
    >
    > This being our architecture , i have the following doubts
    >
    >    1. Instead of having Business Objects and Entities seperately , can
    >       we combine these two. Is it a good approach ??
     
    No, it's not a good approach. You want abstraction away from the model.
    Your BLL should be unaware of the model. The only thing the BLL should
    be aware of is the CRUD methods in the DAL.
     
    >    2. Since the client is web based , is it Ok to use Self tracking
    >       entities ??
     
    >    3. Could be send me some links on how to optimize peformance
    >
     
    You could have this too.
     
    UI
    Model View Presenter
    Service Layer  - not to be confused with the WCF service.
    WCF service
    BLL
    DAL
    Model
     
    You can use complied queries, because the compiled query stays in static
    memory until the ASP.NET Worker Process is recycled.
     
     
    You can also use compiled views if the model is a large model.
     
     It's an issue you may have to deal with a multi user application using EF.
     
     
    • Marked as answer by sabarish_s Friday, June 24, 2011 5:57 PM
    Wednesday, June 22, 2011 7:32 PM

All replies

  • Hi,

    A couple of things.

    First of all, just to clarify, since you don't plan to use Code-First, are you planning to use the DbContext API when generating code from your model? If not, you don't use EF 4.1, but EF 4. In addition you are talking later in your post about using STE, STE is not implemented in DBContext API, but in standard ObjectContext API and you won't use EF 4.1.

    Next, you're saying that already from your BLL you will use custom DTO's to send through your WCF layer up to the MVC, you won't need to use STE, you could simply go for standard entity objects. STE is an option to DTO, which you can use if you want to send complete entities to the MVC, modifying them there and send them back. If you don't plan to do this, STE is just a unneccessary step for you.

    Last, I recommend you to read http://msdn.microsoft.com/en-us/library/cc853327.aspx for how to optimize the use of entity framework.


    --Rune
    Wednesday, June 22, 2011 4:01 PM
  • Hi Rune ,

    Thanks for the link ... Will go through it...  I do not have much knowledge in using  EF 4.1 . So in a situation when there should be  stored procedure support and EF4.1 needs to be used, what will be better architecture ??

    Regards

    Sabarish

     

    Wednesday, June 22, 2011 6:32 PM
  • On 6/22/2011 6:34 AM, sabarish_s wrote:
    > Hi Everyone ,
    >
    > The proposed architecture of our new application is as given below
    >
    >    1. *Presentation Layer*
    >       This will be an ASP.NET MVC application running on mobile
    >    2. *Services Layer*
    >       This will be a WCF Services . The Presentation layer communicates
    >       with the services using custom DTO.
    >    3. *Business Logic Layer*
    >       this is a normal c# class library where all the businnes related
    >       logic are written. This layer exposes Business objects to the
    >       services layer. The services layer uses an entity translator to
    >       convert Business objects in to DTOs
             That's called a 'mapper'.
     
    >    4. *Database Access Layer
    >       *We are plannning to EF4.1 for this. We would like to have stored
    >       procedure support. Hence the plan is to use Model First approach
     
    Yeah you can use sproc as needed using the EF model. You can do the
    queries using Linq-2-Entities, and on the other hand, you can use sprocs
    for ADD, Update and Delete used by the EF model.
     You can either bring the EF entity to the BLL from the DAL or use DTO(s)
    between the BLL and DAL using a mapper too.
     
    >
    > This being our architecture , i have the following doubts
    >
    >    1. Instead of having Business Objects and Entities seperately , can
    >       we combine these two. Is it a good approach ??
     
    No, it's not a good approach. You want abstraction away from the model.
    Your BLL should be unaware of the model. The only thing the BLL should
    be aware of is the CRUD methods in the DAL.
     
    >    2. Since the client is web based , is it Ok to use Self tracking
    >       entities ??
     
    >    3. Could be send me some links on how to optimize peformance
    >
     
    You could have this too.
     
    UI
    Model View Presenter
    Service Layer  - not to be confused with the WCF service.
    WCF service
    BLL
    DAL
    Model
     
    You can use complied queries, because the compiled query stays in static
    memory until the ASP.NET Worker Process is recycled.
     
     
    You can also use compiled views if the model is a large model.
     
     It's an issue you may have to deal with a multi user application using EF.
     
     
    • Marked as answer by sabarish_s Friday, June 24, 2011 5:57 PM
    Wednesday, June 22, 2011 7:32 PM
  • I think you are on the right track with your architecture.

    Seperate the layers as you have described above. Use DTO objects from the BLL up to the presentation and back, and convert them to and from entity objects in your business layer. Some people tend to have an additional layer between the BLL and the Model (called Data Access Layer aka DAL) which can be good to have so it could be easier to switch your database access to some other system later. This layer should then be responsible for converting DTO to and from entity objects.

    In your model, you can map stored procedures to the entities for Insert/Update/Delete so when you are calling SaveChanges on your context, they are executed instead of standard Insert/Update/Delete statements.

     


    --Rune
    Wednesday, June 22, 2011 7:57 PM