ASP.Net Web application architecture RRS feed

  • Question

  • Hello All

    I am in the process of defining high level technology stack or architecure for a web application which will in the future be hosted on a Azure . we have the data model ready and the approach taken is the 'Shared Database and Shared Schema'  with same set of tables used by multiple tenants.

    Below are few thoughts of mine...

    1) UI -- ASP.Net Web forms , we have around 3 Months for the first release so i am gearing towards this otherwise the option is ASP.Net MVC. 

    2) Business Layer --  Thinking of using WCF but when all the data is coming from an on premise database or from a database where the applicaton can connect to i was thinking of using plane Old Dll's

    3) Data access  --  Entity Framework (one advantage is reduced code) but plain old data application block or ADO.Net is faster.

    The user base for this application is not going to be huge (may be around 500 users)

    Please let me know your thoughts on this



    Tuesday, April 24, 2012 3:15 PM

All replies

  • I'm sure everyone will have their own feedback on this, but these are my initial thoughts...
    1. On this, I would consider how long you will need to maintain your application, not just the time to market. In my experience, MVC is easier to maintain in the long run due to the forced separation of concerns. If that is a requirement for you, I would suggest MVC over Web Forms, even though the up-front development time may be a little longer.
    2. I like WCF as an interface for the data layer. If your data is coming from a server on the local network, you can look at using NetTcpBinding and hosting your data layer behind a Windows service for better performance (see Patterns and Practices Securrty Guidelines for more information). I would opt for WCF over simple Dlls if you need your application to be maintainable and adaptable long-term. If your'e just writing a temporary application with a short-term lifecycle, simple Dlls are probably fine.
    3. For data access, use what you know and what you can get up and running quickly. Performance for ORMs is a non-issue for most applications. Performance should only be a deciding factor if you can actually measurably demonstrate that improving ORM performance would noticeably improve overall application performance (which is almost never the case). Personally I tend toward EF, but I know a lot of people who prefer NHibernate. I think it comes down to what you know better, and whether you prefer setting up mappings through the UI or editing HTML files yourself. I also prefer LINQ to Entities over any of the NHibernate APIs. ADO.Net is great for simpler applications, but for any complex scenarios where you need to manage relationships or persist parent/child classes, it will bog you down.

    Check out My Blog. Now updated to actually work!

    Tuesday, April 24, 2012 8:02 PM
  • Tim

    Thanks for your response.

    We are thinking of using Web forms for now as we have deadline approaching in 2-3 months as the clients are expecting us to showcase something by that time. The learning curve is going to have an impact when a lot of pages require databound controls.

    For the business layer as suggested we are going ahead with WCF but also looking at building REST full services using WCF. As this application will eventually go on cloud I am guessing in future there may be clients who would like to consume just the services.

    Data access as suggested we will use entity framework but we are also looking to see if we can add data services as interface to the data form EF.

    Please let me know your thoughts



    • Proposed as answer by preethii Wednesday, May 9, 2012 10:14 PM
    Wednesday, April 25, 2012 1:16 PM
  • Hi Ramee,

    I am a developer,now designing architecture(im new to this) for insurance project.

    I am in the process of designing secure architecture using Presentation layer,wcf(interface layer),DAL.

    If your done with the designing(architecture )could you please share.


    Wednesday, May 9, 2012 10:20 PM
  • There have been some changes to the requirements (we dont have service layer now) Overall the architecture is now a simple 3 layered application

    Presentation -- Web forms

    Business  --  Well defined business managers (will be using business objects (POCO))

    Data access  --  Entity framework with database first approach. I will be abstracting this layer using a lightweight repository pattern (gives me ability to mock during unit testing)

    We are going for custom authentication as we have our won roles features and user tables



    Tuesday, May 22, 2012 3:22 PM