architecture
-
Hi, Is it a good practice - to first create a DB, then data layer and business layer and then web services that communicates between the business layer and the front end of all the different websites - like admin, corporate, product website? The idea is to minimize the direct interaction of front end layer with the back end and instead place web services in between? or please let me know if there is better approach(No MVC for now..)
-
Hi, Is it a good practice - to first create a DB, then data layer and business layer and then web services that communicates between the business layer and the front end of all the different websites - like admin, corporate, product website? The idea is to minimize the direct interaction of front end layer with the back end and instead place web services in between? or please let me know if there is better approach(No MVC for now..)
I think better approach may be to go backwards to what you written. So first you create a GUI for a functionality. Then you write some logic of the GUI, that calls service, which in turn calls business layer method/methods and business layer performs operations on database. In this approach important thing is not to implement all layers at once. First you design GUI. Because GUI is most important in the application (this is what user sees and he really doesn't care, that underneath there is super database design if GUI sucks). When you have GUI, you can prepare some logic for it. Here you decide what services you need and create interfaces of these services. You don't implement services yet. You just create some implementation that returns constant data. When logic of GUI is completed you can start implementing services for real. Implementation of services gives you idea of what business layer should contain and you do the same with business layer as with services earlier: simple implementation without real logic. In the end you create data access layer. And database. And they are result of what you really need, not what you think you'll need.
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
-
I think better approach may be to go backwards to what you written. So first you create a GUI for a functionality. Then you write some logic of the GUI, that calls service, which in turn calls business layer method/methods and business layer performs operations on database. In this approach important thing is not to implement all layers at once. First you design GUI. Because GUI is most important in the application (this is what user sees and he really doesn't care, that underneath there is super database design if GUI sucks). When you have GUI, you can prepare some logic for it. Here you decide what services you need and create interfaces of these services. You don't implement services yet. You just create some implementation that returns constant data. When logic of GUI is completed you can start implementing services for real. Implementation of services gives you idea of what business layer should contain and you do the same with business layer as with services earlier: simple implementation without real logic. In the end you create data access layer. And database. And they are result of what you really need, not what you think you'll need.
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
I quite like this backwards approach but most of the developers always say it's best to write DB first. But never mind, the problem that i can see in this architecture is - if there is a problem in web service then all the sites go down at the same time. How can i overcome this problem? I don't think it will be a good idea to develop different web service for each websites.
-
Hi, Is it a good practice - to first create a DB, then data layer and business layer and then web services that communicates between the business layer and the front end of all the different websites - like admin, corporate, product website? The idea is to minimize the direct interaction of front end layer with the back end and instead place web services in between? or please let me know if there is better approach(No MVC for now..)
There are arguments pro and con for both top down and bottom up methods but the only correct answer is what works for you situation, your project, your team, your goals. Not every project requires the use of Web Services. You have to weight the costs and benefits. If the application you are building is an internal app on a single platform, then Web Services are more of a hindrance. If, on the other hand, your business logic may be used by other companies, or divisions within the company, then it may be worthwhile.
I know the language. I've read a book. - _Madmatt
-
Hi, Is it a good practice - to first create a DB, then data layer and business layer and then web services that communicates between the business layer and the front end of all the different websites - like admin, corporate, product website? The idea is to minimize the direct interaction of front end layer with the back end and instead place web services in between? or please let me know if there is better approach(No MVC for now..)
Yes, if that's what your situation calls for. I would put an API between the business layer and the Web Services though.
My general rule of software development: "Design should be top-down, but implementation should be bottom-up."
modified on Tuesday, August 2, 2011 9:13 AM
-
Hi, Is it a good practice - to first create a DB, then data layer and business layer and then web services that communicates between the business layer and the front end of all the different websites - like admin, corporate, product website? The idea is to minimize the direct interaction of front end layer with the back end and instead place web services in between? or please let me know if there is better approach(No MVC for now..)
In my opinion you can remove the impact of the entire design choice by having a good up front design that handles all aspects you mentioned. You talk about the technical design, but you need a functional design first. A functional design focuses on use cases, workflows etc... EG.: Functional: A user says he wants a dialog that holds a person's information and that has buttons to save the information, copy the information and close the dialog. He also explains what that 'information' is, in detail. (name, first name, age, etc...) The user mentions how this information is used in other parts of the application and or system or even in other applications or systems. You can give some direction to the user here like do you want to have a remote service for this? (indicating pro's and con's) Technical: Based on the information of thze technical information you can design the application technically, will we use services, forms/wpf or web UI's? What dataobjects can we define? How many tiers do we need, etc... This can go as far as defining the SQL statements necessary and writing propotypes. Hope this is what you wanted.
V.
-
Hi, Is it a good practice - to first create a DB, then data layer and business layer and then web services that communicates between the business layer and the front end of all the different websites - like admin, corporate, product website? The idea is to minimize the direct interaction of front end layer with the back end and instead place web services in between? or please let me know if there is better approach(No MVC for now..)
In implementing the app, yeah. It's good. In design mode or user talks or functionality it is the other way around. First talk to the users, see what(functionality) they want, how they want it(technical data such as web app, win app...). Then, after all data about the app is gathered, start with the DB. That's how I do it. I may be wrong, but don't tell anybody. :)
All the best, Dan