best way to design my UI for maintainability when using editable datagridview

I'm working on a user interface which when completed will contain the data from a lot of different tables in our database. I have questions regarding the design of my app to reduce the amount of duplicated code while increasing the ability to maintain this app in the future. We plan to use it many places (and continue building more features) so getting the initial design correct is quite important to me. Due to my lack of experience and the constraints stacked against me I am not sure where to look for a solution, allow me to explain...

I started by picking one table and setting up a bindingsource, a sqlcommandbuilder, a sqldataadapter, and a dataview. Getting basic crud operations, filtering, and sorting to work wasn't that bad.

The cell validation logic required quite a bit of code that referenced columns by name and it was brought up during a code review that this wasn't the best practice given the planned size of this program. It would lead to lots of maintenance when we did simple things like add another column or rename a column.

Based off these comments we reached two conclusions:

1. we could take our validation logic and turn it into business rules and create a business logic layer. That was a bit better but not everyone was sure that's the best approach.

2. we could probably avoid all validation logic by enforcing constraints on our actual tables in the db and then create views for every table my UI consumed (that way they can add a new column without UI changes). This i'm not really sure about though. Never considered an approach like this.

I got a comment from a peer that big dev shops don't spend their time hardcoding validation logic like this unless they are making a one-off app. I wasn't sure how to respond to this because I always thought they did :ehh:. The example provided to go with that comment was sql server management studio. It is written in such a way that it doesn't have to know anything about your schema and still can still allow you to display and edit your whole db.

The use of tools which generate strongly typed datasets and the sort are frowned upon and not used.

It seems like what is expected here is a very OO type of app but with minimal efforts building the objects. The whole "having my cake and eating it too" phrase comes to mind here. I understand I can make base classes for my forms to inherit which will contain the bindingsource,data containers, command builders, etc. What I don't seem to get is how I am to have a working editable/sortable/filterable datagridview without actually writing any code to support the data my table is bound to? Maybe that's where the business objects will help?

My argument in all of this is that in every given program there has to be a point where you are willing to accept some hardcoded values. After all, if you want it to work you have to put code *somewhere* that knows about the context of the data.

I hope my thread makes sense and someone here can give me a bit of insight as to how I can best proceed to meet these requirements. If you think that what i'm asking for is near impossible then let me know. I am beginning to think that's the case. Thanks for taking the time to read my post and have a good day!

High level, remove the majority of validation from forms and create projects that are responsible for business rules. There will be some things that will be kept in the form projects but should be only what can't be placed into a business layer project. Hard coding is only bad when done improperly and without thought. Attempting to be fluid (getting into reflection etc.) to the n'th degree can make code un-maintainability even to the person who coded said code.

In our shop with well over 30 desktop applications one can count on 95% of the projects to be laid out exactly the same. There is no guessing how one accesses data or validates user input. This did not happen overnight but was done while in our first few projects.

Our web team is very similar to what our desktop developers did, have pre-done code used by many apps, in this case in Java and JQuery. Now we are moving some desktop apps to the web and since business logic did not reside in the form projects moving this code to WCF projects and working with JSON was a fairly smooth transition.

I appreciate the response Kevin. Business logic layer is what i've been working on the last couple of days.