Architectural designs and technology


I'm looking to get some feedback on the best approach to designing a new system.

Basically our company like to keep all the business logic contained within the database(stored procedures), its always been like this and needs to stay the same. So we have been asked to come up with new layered applications using the latest .NET Core with VS2017 (MVC & WPF MVVM). The reason these 2 have been mentioned is that they are the best way forward in terms of web and windows based correct me if I'm wrong.

My question is...What would be the best way to design layers around keeping business logic in DB?

Having not used any of these technologies I'm looking to find good examples of how I can approach setting up layered architecture, based on our business needs.

Could we use EF7 using stored procedures or EF using LINQ? or just use plain old without EF?

Could we still use layers like so with or without EF (Presentation Layer, Service Layer(API), Business Layer, Data Layer)? Either way any examples would be great.

And could both technologies both benefit using these layers -> Service Layer(API), Business Layer, Data Layer for reusability?

Any feedback most welcome and appreciated.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Miguel OzSenior Software EngineerCommented:
My preference will be: (Presentation Layer, Service Layer(API), Business Layer, Data Layer and having a Utils class that contain the general helper classes and methods you may have.
Having an API make things simpler in terms of encapsulating and sharing your logic among multiple products.
Also, you should use EF7, it is used to map your DB tables to objects in your code and yes you can run store procedures and use LINQ
in the results.
For web I will consider ASP.NET Core , also adding a JavaScript framework like angular or react (depending on how the UI user specs are)  and CSS framework like Bootstrap.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
PawełI Design & Develop SoftwareCommented:
It's a matter of opinion, personally i think you guys made a great decision by keeping your logic in stored procedures, now it really doesn't matter what design pattern you use, you can just leverage the Stored procedures in your db, and just use your applications as data consumers, almost like thin clients, your applications are just getting and posting information.

I wouldn't access the data directly from your applications, i'd build a webservice that exposes end points your applications can interact with and have the web-service interact with the database. at the webservice layer you could most definitely leverage entity framework, but that's just a matter of preference.

anyway i'm sure someone will disagree with me, but it sounds like you've got it figured out and are on the right track
razza_bAuthor Commented:
Thanks for your comments guys, as you say its a matter of preference and also getting to know and understand the architecures.


Using the web service/web service layer interact with the Data layer does that mean using no BL classes?
just trying to get my head around the whole layered thing with MVC and ASP.Net. how would that work?

Also do you guys have any examples I can follow to see how all this hangs together?

PawełI Design & Develop SoftwareCommented:
what we're discussing really isn't new, here's a link to get you started.

I think it's a webforms example, but ignore that part, focus on the idea, not the implementation.

the idea is that the data access layer (DAL) gives you access to the DB, so that you can have multiple consumers of the same data go through the same entry-point, then if you need to change the Data layer you only have to worry about the web-service (DAL). and if you want to make a webapplication, a native ios app, and a UWP app the they can all use the same webservice for CRUD operations to the database.

as for your Business layer, you can put it wherever you please, personally I'd enforce my rules at the DAL, to ensure whoever creates the different consumers applications can't mess up my database. it's fair to say that the various consumers will also need to leverage Business rules so putting them into a portable class library probably makes sense.
Miguel OzSenior Software EngineerCommented:
@Pawel: I do agree with "enforce my rules at the DAL", thus the reason why my comment added BL to the service.
@razza_b: You could  have 2 business layers:
- UI business layer. (e.g. custom html helper classes)
- Service business layer. (e.g. what ever rules)
It all depends of project needs.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.