Point of Sale Application - Architecture - Data Layer RRS feed

  • Question

  • Entity Framework 4.0, Linq To Sql, DataReader using enterprise library 5.0 all this are options for me to construct data layer.

    I have gone thru lots threads on performance related issue about using ORM Mapper or Simple Data Access technique like ormbattle.net, http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html.

    I myself have done practically pros and cons of above, i decided to move with simple data access technique "DataReader" using enterprise library 5.0 as the Point of sale application (win forms 4.0) will run over POS Terminal where the main purpose is your transaction should be as much as possible fast to place more order.

    As i have no use of any ORM features due to my most code will be from stored procedure i have taken this steps.

    Please suggest is the simple data technique good for point of sale application to achieve better performance?




    Friday, October 8, 2010 4:00 AM


  • Tools like Entity Framework 4.0 can save you a lot of time developing the data access layers, and if you are developing a new application from scratch may end up being worth using. Performance of EF is pretty good from my testing. I cannot use in our apps so we use a DataReader approach and build our own business objects and logic by hand, but part of the problem we ran into is that we were working with a legacy database in MySQL and I ran into some issues mapping some of the stuff we did in MySQL to Entity Framework. If I was building the database from scratch, I would not be doing things that way (dynamically creating table names at runtime is one thing we do) so it would map better to Entity Framework, but either way performance is going to be good.

    Just bear in mind that with the Entity Framework is makes it easier to build mocking object for doing Unit Testing for the service layers, since you can easily build a mocking library to fake the results from the EF that your business logic can use. So Unit Testing is simpler and faster. If you are Unit Testing code using DataReaders, it makes it much more difficult to separate data acces from the business logic, because when you write code using a DataReader you are writing SQL code directly. And when you manually write SQL code, the SQL code becomes a part of the business logic and also needs to be unit tested.

    So what we do is build a special Unit Test database that is small, fast and contains exactly the data needed for the tests. Then we simply test against that :)

    Friday, October 8, 2010 10:36 PM