5

For a good start to reading see this wikipedia list. Ideally, you are looking at separation of concerns. While a more general solution has advantages for reuse between projects, there is a problem. The database is concerned with storing the data, and so it is the job of the database to know what the data is. You don't want a table that can store anything ...


5

As usual, the answer is: it depends. There are lots of issues to consider, including: first and foremost, what the customer wants and is willing to pay for the difference in implementation and maintenance cost and risks between the alternative solutions the expected lifetime of the product the expected scope of future changes (i.e. is it reasonably expected ...


3

My answer ultimately is similar to Péter Török's in that I believe it depends on the additional effort and complexity of implementing the Generalized solution. Framing this as a implementaiton argument though is a mistake, and labeling the two opposing sides by programming language and defining that in the way they think is dangerously close to creating the ...


2

One of the key aspect of MVC is that the model is independent of the views. In fact the model can be represented by several views, and each change to the model data should be displayed in all the relevant views (typically using the observer pattern). So if you start an MVC design by foreseeing a hard-wired mapping between specific model classes and specific ...


1

For the main, I'd keep the pairs within discipline - so, UI guys would predominantly pair with another UI person, DB guys would pair with another DB person. If you only have one or two in a discipline, then so be it - you can't always pair when you don't have the numbers. You are right that a UI specialist would not want or be needed to fill in for a DB ...


Only top voted, non community-wiki answers of a minimum length are eligible