Project Architecture
-
Hi, I have inherited what I would call a badly designed database using SQL Server. At the moment the application that uses the database has an Access 97 front-end and with XP now being end of life, I have been tasked with creating a new application to replace Access 97. I am looking quite a bit into the project architecture to future proof the application and also for best practices. I have been reading into using a 3-tier architecture - DAL, BLL and UI. I originally started looking into using EF but it doesn't seem overly compatible with my database as there are quite a few tables that don't have PK's and we already have a lot of stored procedures that will be used rather than directly to the table. I have currently decided that I will use ADO.Net but can't help but feel that is a bad decision. I really have a couple of questions here - 1 - What project architecture do people generally use these days and what is best practice, can you provide me with some examples? 2 - If I continue down the ADO.Net route do I create different classes for the different Stored Procedures that are used? 3 - Am I making the right decision using ADO.Net? Any help/advice/links are greatly appreciated.
Personal Blog: A Software Programmer Twitter: JammoD
-
Hi, I have inherited what I would call a badly designed database using SQL Server. At the moment the application that uses the database has an Access 97 front-end and with XP now being end of life, I have been tasked with creating a new application to replace Access 97. I am looking quite a bit into the project architecture to future proof the application and also for best practices. I have been reading into using a 3-tier architecture - DAL, BLL and UI. I originally started looking into using EF but it doesn't seem overly compatible with my database as there are quite a few tables that don't have PK's and we already have a lot of stored procedures that will be used rather than directly to the table. I have currently decided that I will use ADO.Net but can't help but feel that is a bad decision. I really have a couple of questions here - 1 - What project architecture do people generally use these days and what is best practice, can you provide me with some examples? 2 - If I continue down the ADO.Net route do I create different classes for the different Stored Procedures that are used? 3 - Am I making the right decision using ADO.Net? Any help/advice/links are greatly appreciated.
Personal Blog: A Software Programmer Twitter: JammoD
JammoD87 wrote:
1 - What project architecture do people generally use these days and what is best practice, can you provide me with some examples?
EF is the most mentioned out-of-the-box ORM's around here. LINQ is mainly something used on collections, and sometimes there's a mention of NHibernate. Most go for some custom implementation tough.
JammoD87 wrote:
2 - If I continue down the ADO.Net route do I create different classes for the different Stored Procedures that are used?
That's possible, if you'd want to.
JammoD87 wrote:
3 - Am I making the right decision using ADO.Net?
Yes. Well, EF makes a close second; I don't have hands-on experience with it, but heard good things about it. ADO has been there since .NET, and there's a lot of documentation on the subject. I'd say it is the path that has proven to work, with EF looking as a nice new alternative.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
JammoD87 wrote:
1 - What project architecture do people generally use these days and what is best practice, can you provide me with some examples?
EF is the most mentioned out-of-the-box ORM's around here. LINQ is mainly something used on collections, and sometimes there's a mention of NHibernate. Most go for some custom implementation tough.
JammoD87 wrote:
2 - If I continue down the ADO.Net route do I create different classes for the different Stored Procedures that are used?
That's possible, if you'd want to.
JammoD87 wrote:
3 - Am I making the right decision using ADO.Net?
Yes. Well, EF makes a close second; I don't have hands-on experience with it, but heard good things about it. ADO has been there since .NET, and there's a lot of documentation on the subject. I'd say it is the path that has proven to work, with EF looking as a nice new alternative.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Hi, I have inherited what I would call a badly designed database using SQL Server. At the moment the application that uses the database has an Access 97 front-end and with XP now being end of life, I have been tasked with creating a new application to replace Access 97. I am looking quite a bit into the project architecture to future proof the application and also for best practices. I have been reading into using a 3-tier architecture - DAL, BLL and UI. I originally started looking into using EF but it doesn't seem overly compatible with my database as there are quite a few tables that don't have PK's and we already have a lot of stored procedures that will be used rather than directly to the table. I have currently decided that I will use ADO.Net but can't help but feel that is a bad decision. I really have a couple of questions here - 1 - What project architecture do people generally use these days and what is best practice, can you provide me with some examples? 2 - If I continue down the ADO.Net route do I create different classes for the different Stored Procedures that are used? 3 - Am I making the right decision using ADO.Net? Any help/advice/links are greatly appreciated.
Personal Blog: A Software Programmer Twitter: JammoD
If you are already using ADO.net I wouldn't suggest you to go with EF. If you wish to use EF you can use it You can even use your existing stored procedures if you want but may have to do some changes. The decision with EF or ADO.net depends on other factors also like 1) if you want better performance and working on huge data then go with ADO.net. 2) Whatever you are comfortable with. If you have a very good expertise in ADO.net then go with ADO.net or if you have very good expertise in EF then go with EF. Instead of a 3-tier architecture I would suggest you to try GUI Architectural patterns either MVVM or MVC depending on the type of the application. If you want to use 3 tier architecture then there may be more layers required to have separation of concerns e.g:- for cross cutting concerns etc.