locked
Should we use middleware RRS feed

  • Question

  • User1842222572 posted

     hello everyone,

    I am relatively inexperienced  with ASP.NET and the web development.  I recently worked with a few developers on a couple of projects for developing web applications and we didn't use any Middleware and were directly connecting to SQL Server databases. I did some research on why we need to use a Middleware but couldn't find any satisfactory (easy to understand) answers.

    Can anyone please help me understand why we need Middleware and why didn’t it matter on the projects that I worked on (nobody even talked about Middleware). Does it matter if the application is simple/small?

    Thank you in advance!!

    Monday, February 9, 2015 10:04 PM

Answers

  • User541108374 posted

    Hi,

    it's not by default bad. Thing is that it's more like demo ware or to quickly make up things to test them. Basically you're opening a direct channel to your database from your page. What if you also wanted to expose your site as mobile app? That's a common request nowadays from the CIO as everything has to become mobile or at least your company needs to have presence in that space.

    In that case you would have to create your mobile application but also have to deal with copy pasting, in the best case, the sql statements made up in your SqlDatasource. What if you took it apart and put data access in a separate place already in your web application? In that case you could introduce a service/middleware in between that both your web application and your mobile application could call. The data access stays the same so you directly benefit of reuse. Also maintenance might become easier as if there's something wrong in retrieval of data you have to plunge into one place. In the case of using the SqlDatasource and copy pasting the stuff in the mobile application you'll find yourself in the situation where you need to change 2 applications, retest them, get them deployed, ... 

    Grz, Kris.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, February 11, 2015 4:27 AM
  • User-1611549905 posted

    Thanks Kris,

    can you please, in layman's terms explain why using SqlDatasource is a bad practice and how middleware addresses these issues/bad practices? thanks again..

    In a word: testability.

    In professional software development, one of the key drivers for architectural design is the ability to test different parts of your codebase in isolation from each other. For example, you may need to verify that VAT (sales tax if you're US-based) is being calculated correctly, or that data being saved to the database is being returned in the correct format for use by the rest of your application.

    In order to do this, you need to introduce a certain separation of concerns between different parts of your code -- for example, you may wish to replace your database with a mock object in order to test that your queries are returning the correct results. You can't do this in every case, as sometimes performance requirements introduce tighter coupling between the layers, in which case you would have to go through a test database, but in general where you can do so then you should.

    The problem with the SqlDataSource is that it is very difficult to test it in this way. The SqlDataSource is really designed for dragging onto a forms designer and using a point-and-click approach to connecting your database to your UI, so as such it doesn't offer any entry points where you can introduce mock objects to verify that it is returning the correct results. The only way you can really test it is by doing an end-to-end integration test from the front end right through to the database using Selenium for example. This is generally viewed as insufficient as end-to-end UI-based tests are slow, fragile, and difficult to maintain, so they are generally used in conjunction with unit tests.

    As Kris said, SqlDataSource tends to be most useful for demonstration code -- like the "create your own blog engine in fifteen minutes" demos that you used to see at tech conferences about ten years or so ago. Having said that, it does also find some utility for quick-and-dirty throwaway code, though it's not really suitable for serious work.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, February 11, 2015 4:44 AM

All replies

  • User-37275327 posted

    Middleware is the term use to identify the technology lies between different technologies.

    Ex : Webservice, which can be communicated by JAVA, ASP.NET or other. Reference.

    What ever technology which can bridge the gap can be called as "Middleware".

    Monday, February 9, 2015 11:58 PM
  • User1842222572 posted

    I am not sure I understand your answer. 

    Sorry this statement "Middleware is the term use to identify the technology lies between different technologies." doesn't make sense to me.

    Tuesday, February 10, 2015 12:02 AM
  • User-37275327 posted

    In other words technology which heterogeneous technology/systems to communicate.

    Tuesday, February 10, 2015 1:45 AM
  • User541108374 posted

    Hi,

    I did some research on why we need to use a Middleware but couldn't find any satisfactory (easy to understand) answers

    Which articles did you read? Please always provide what you already tried / consulted.

    The answer: it depends. On the architecture set out by the company (always use services or not), the budget of the project (making more layers costs more time hence money), ...

    If you used something like SqlDatasource controls then likely you're doing it wrong from a maintenance and clean architecture point of view. It's great for demos and quick quick applications. If you however created several different layers and cleanly separated these, traditionally presentation, business, data access layers then you already have a nice basis to start from. If for some reason later on you need to add a service layer / middleware in between it takes time and effort but you can more cleanly do it. Traditionally that's placed between the presentation and business layer in that case. WCF or Web API or web services are usually used in that case.

    Grz, Kris.

    Tuesday, February 10, 2015 3:39 AM
  • User753101303 posted

    Hi,

    Or could it be some kind of allusion to Entity Framework if this is not what you are using already ? Middleware is quite vague. For now it seems you expect this to be between your application and the SQL database so this is my first thought about your particular context....

    Or just tell how you currently access the db and one will suggest possible alternatives without using jargon ?

    Tuesday, February 10, 2015 7:34 AM
  • User1842222572 posted

    Thanks Kris,

    can you please, in layman's terms explain why using SqlDatasource is a bad practice and how middleware addresses these issues/bad practices? thanks again..

    Tuesday, February 10, 2015 5:30 PM
  • User541108374 posted

    Hi,

    it's not by default bad. Thing is that it's more like demo ware or to quickly make up things to test them. Basically you're opening a direct channel to your database from your page. What if you also wanted to expose your site as mobile app? That's a common request nowadays from the CIO as everything has to become mobile or at least your company needs to have presence in that space.

    In that case you would have to create your mobile application but also have to deal with copy pasting, in the best case, the sql statements made up in your SqlDatasource. What if you took it apart and put data access in a separate place already in your web application? In that case you could introduce a service/middleware in between that both your web application and your mobile application could call. The data access stays the same so you directly benefit of reuse. Also maintenance might become easier as if there's something wrong in retrieval of data you have to plunge into one place. In the case of using the SqlDatasource and copy pasting the stuff in the mobile application you'll find yourself in the situation where you need to change 2 applications, retest them, get them deployed, ... 

    Grz, Kris.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, February 11, 2015 4:27 AM
  • User-1611549905 posted

    Thanks Kris,

    can you please, in layman's terms explain why using SqlDatasource is a bad practice and how middleware addresses these issues/bad practices? thanks again..

    In a word: testability.

    In professional software development, one of the key drivers for architectural design is the ability to test different parts of your codebase in isolation from each other. For example, you may need to verify that VAT (sales tax if you're US-based) is being calculated correctly, or that data being saved to the database is being returned in the correct format for use by the rest of your application.

    In order to do this, you need to introduce a certain separation of concerns between different parts of your code -- for example, you may wish to replace your database with a mock object in order to test that your queries are returning the correct results. You can't do this in every case, as sometimes performance requirements introduce tighter coupling between the layers, in which case you would have to go through a test database, but in general where you can do so then you should.

    The problem with the SqlDataSource is that it is very difficult to test it in this way. The SqlDataSource is really designed for dragging onto a forms designer and using a point-and-click approach to connecting your database to your UI, so as such it doesn't offer any entry points where you can introduce mock objects to verify that it is returning the correct results. The only way you can really test it is by doing an end-to-end integration test from the front end right through to the database using Selenium for example. This is generally viewed as insufficient as end-to-end UI-based tests are slow, fragile, and difficult to maintain, so they are generally used in conjunction with unit tests.

    As Kris said, SqlDataSource tends to be most useful for demonstration code -- like the "create your own blog engine in fifteen minutes" demos that you used to see at tech conferences about ten years or so ago. Having said that, it does also find some utility for quick-and-dirty throwaway code, though it's not really suitable for serious work.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, February 11, 2015 4:44 AM